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1.0  INTRODUCTION 

This  document  is  one  of  three  documents  explaining  the 
Nuclear  Damage  Assessment  Code  (NUCDAM) .  Volume  I  contains  user 
information  about  the  various  versions  of  NUCDAM  currently 
operating  in  the  Fleet  and  the  configuration  management  plan  by 
which  changes  to  NUCDAM  are  initiated.  Volume  II  is  a  classified 
document  which  contains  explanations  and  listings  of  the  environ¬ 
ment  and  impairment  routines  utilized  by  the  NUCDAM  code.  Volume 
III  is  a  classified  document  that  contains  information  about  the 
necessary  vulnerability  data  associated  with  the  operation  of 
this  code. 


2.0  BACKGROUND 


The  T'uclear  Damage  Assessment  Module  (NUCDAM)  was  developed, 
by  Kaman  Sciences  Corporation  (KSC)  for  CNO  (OP-654) ,^to  be  used 
in  the  Naval  Nuclear  Warfare  Simulation  (NNWS)  for  calculating 
damage  to  naval  units  involved  in  tactical  nucleax^engagements  at 
sea.  /^The  Environment  program.11  were  developed  in  three  phases*.  '  & 

The  Phase  I  damage  assessment  model  (Reference  1)  included 
the  capability  to  calculate  damage  to  submarines  and  surface 
ships  from  underwater  nuclear  bursts  created  by  Anti-Submarine 
Warfare  (ASW)  engagements.  This  included  calculating  damage  from 
the  effects  of  peak  translational  velocity  (ft/sec) ,  excessive 
impulse  (psi-sec)  and  energy  flux  density  (ft-psi) . 

The  Phase  II  damage  assessment  model  (Reference  2)  expanded 
the  Phase  I  model  to  include  the  capability  to  calculate  damage 
to  surface  ships  from  air  and  surface  nuclear  bursts  produced  by 
Anti-Surface  Warfare  (ASUW)  engagements.  In  addition  to  ASUW 
engagements,  the  nuclear  effects  include  calculating  damage  from 
the  effects  of  overpressure  (psi) ,  EMP  (v/m) ,  neutron  f luence  for 

I  MV  equivalent  (n/cma) ,  total  ionizing  dose  (rems) ,  and  thermal 
exposure  (cal/cma). 

The  Phase  III  effort  (Reference  3)  incorporated  into  Phase 

II  the  nuclear  weapons  effects  that  may  influence  the  outcome  of 
ASW  engagements.  These  additional  nuclear  weapons  effects  from 
underwater  bursts  included  the  blast  overpressure  along  the 
surface  of  the  water  (psi) ,  the  peak  dose  rate  from  the  base 
surge  (RADS/HR) ,  the  total  dose  from  the  base  surge  (RADS)  and 
the  peak  translational  velocity  (ft/sec)  which  include  the 
effects  of  bottom  reflection.  The  modifications  of  NUCDAM  also 
involved  changes  to  the  blast  overpressure  and  radiation  routines 
to  incorporate  more  up-to-date  information  since  they  were 
originally  developed  in  Phase  II. 


The  purpose  of  the  NNWS  Nuclear  Damage  Assessment  Module 
(HOC PAM)-  is  to  determine  the  degree  of  weapon  system  impairment 
to  a  naval  unit  (submarine  or  surface  ship)  that  has  been 
subjected  to  the  effects  of  a  nuclear  burst.  Damage  to  naval 
units  from  a  tactical  engagement  is  determined  by  calculating  the 
nuclear  environment  based  on  weapon  yield  and  weapon-target  geo¬ 
metry  and  then  relating  the  calculated  environment  to  damage 
threshold  parameters  associated  with  the  target  to  determine  the 
degree  of  impairment  to  the  operational  attributes  (OATs)  that 


describe  the  naval  unit. 


The  nuclear  environments  which  have  been  incorporated  into 
the  model  are  underwater  shock  (including  bottom  reflection),  air 
blast  and  radiation  from  underwater  bursts,  and  blast,  thermal, 
initial  radiation,  and  low  altitude  EMP  from  air  or  surface 
bursts.  Damage  predictions  are  made  for  the  submarine 
operational  attributes  of  seaworthiness,  mobility,  weapon 
delivery,  communications,  sensors,  and  personnel  and  for  the 
surface  ship  operational  attributes  of  seaworthiness,  mobility, 
weapon  delivery  (includes  ASH,  and  CM  weapon  systems), 
communications,  sensors,  aircraft  (on  carrier  deck  or  ground), 
and  personnel.  Damage  from  multiple  or  successive  bursts  is 
accumulated  by  one  of  three  methods  based  or.  the  damage  mechanism 
associated  with  the  affected  operational  attribute.  The  avail¬ 
ability  of  each  operational  attribute  is  updated  based  on  the 
damage  mechanism  associated  with  the  affected  operational  attri¬ 
bute.  The  availability  of  each  operational  attribute  is  updated 
based  on  the  accumulated  damage.  The  ability  of  a  unit  to 
successfully  conduct  a  particular  mission  is  determined  by  the 
combined  availabilities  of  the  operational  attributes  required 
for  that  mission.  In  addition  to  calculating  damage  and 
availability,  NUCDAM  contains  an  algorithm  to  calculate  repair 
time  delays  to  determine  if  and  when  the  damage  will  be  corrected 
in  the  affected  capability  area. 


The  develops nl:  of  NUCDAM  generated  a  great  deal  of  interest 
within  the  Naval  training  and  war  gaming  community.  After  the 
development  of  Phase  II,  KSC  created  a  simplified  version  of 
NUCDAM  along  with  an  appropriate  driver  to  operate  on  a  Radio 
Shack  TRS-80  Model  1  microcomputer  for  the  Naval  War  College.  A 
version  of  the  TRS-80  NUCDAM  was  then  implemented  on  the  DNA 
CYBER  at  LASL.  The  CNO  (OP-654)  sponsored  the  development  of  a 
version  of  Phase  II  implemented  on  the  HANG  2200  T/VP  computer  to 
be  used  on  shipboard. 

Under  DNA  sponsorship,  KSC  then  developed  a  stand-alone 
training  and  tactical  decision  aid  for  the  Battle  Group  Training 
Computer  Support  Facility  (BGTCSF)  at  the  Naval  Ocean  Systems 
Center  (NOSC)  based  on  Phase  III.  This  version  was  developed  for 
the  VAX  11/780  to  be  used  in  conjunction  with  NWISS  training. 
This  version  of  NUCDAM  was  then  installed  on  the  HQ- DNA  CYBER  in 
Washington.  Copies  of  this  version  have  been  distributed  to  CNO 
(OP-654)  for  installation  on  the  PDP  11/34,  Boeing  Aerospace 
Company ,  Titan  Sy stems,  Inc.,  and  McDonnell  Douglas  Corporation. 

Another  :.'icv  computer  version  of  NUCDAM  Phase  II  was 
developed  for  .ne  HP9835  to  be  used  for  shipboard  training  in  the 
Fleet.  KSC  also  put  this  version  on  its  PRO-350.  The  latest 
development  for  a  microcomputer  has  been  the  use  of  NUCDAM  Phase 
III  in  the  NAVTAG  Companion  implemented  on  the  WICAT  150  HS. 
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~.0  KKWS  DESCRIPTION 

It;.  T^!JWS  is  designed  to  Model  a  two-sided,  theater-wide 
naval  conflict  over  an  extended  period  of  time.  Players  parti¬ 
cipate  at  a  lv?el  similar  to  that  of  a  Naval  Theater  commander 
through  the  use  of  computer-supported  interactive  graphics.  An 
umpire  function  is  included  to  control  third  party  actions  and 
other  factors  beyond  the  control  of  either  side. 

Figure  1  illustrates  the  various  elements  modeled  in  the 
NNWS.  NNWS  utilizes  a  large  scale  IBM  computer  to  model  the 
actions  and  encounters  of  a  campaign  through  stochastic 
alrogithcs  dependent  on  system  and  platform  effectiveness 
parameters  that  can  vary  as  a  function  of  environment  and 
tactical  situation.  Interaction  with  the  simulation  is 
accomplished  from  minicomputer-controlled  player  stations.  The 
interactive  computer  setup  allow  both  sides  to  direct  the 
employment  of  any  of  their  assets  as  the  campaign  evolves  over 
time.  The  units  of  both  sides  move  in  accordance  with  their 
respective  player  orders  conducting  transit,  strike,  patrol,  or 
support  operations. 

The  player  is  provided  with  periodic  surveillance  informa¬ 
tion  and  significant  reports  from  the  operating  forces  as  the 
campaign  progresses.  Based  on  this  information,  the  player  cay 
reallocate  forces,  assign  strike  or  patrol  missions,  or  modify 
the  Automated  Decision  Rules  (ADR) .  When  opposing  forces 

encounter  one  another,  they  either  evade  or  interact  in 

accordance  with  the  current  ADRs  specified  by  the  player.  The 
results  of  interactions  that  occur  within  the  campaign  are  stored 
and  analyzed  off-line  to  evaluate  the  utility  of  tactical  and 
theater  nuclear  weapon  alternatives,  mixes,  or  employment 
doctrines. 
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Figure  1.  NNWS  Model  Elements 


3.2  NUCDAK  Module 


The  purpose  of  the  NNWS  Nuclear  Damage  Assessment  Module 
(NUCDAM)  is  to  determine  the  degree  of  weapon  system  impairment 
to  a  naval  unit  (submarine  or  surface  ship)  that  has  been 
subjected  to  the  effects  of  a  nuclear  burst.  Damage  to  naval 
units  from  a  tactical  engagement  is  determined  by  calculating  the 
nuclear  environment  based  on  weapon  yield  and  weapon-target 
geometry  and  then  relating  the  calculated  environment  to  damage 
threshold  parameters  associated  with  the  target  to  determine  the 
degree  of  impairment  to  the  operational  attributes  that  describe 
the  naval  unit. 

Damage  predictions  are  made  for  the  submarine  operational 
attributes  such  as  seaworthiness,  mobility ,  weapon  delivery, 
communi-  cations,  sensors,  and  personnel  and  for  the  surface  ship 
operational  attributes  such  as  seaworthiness,  mobility,  weapon 
delivery  (includes  ASW,  SAM,  and  CM  weapon  systems) ,  communica¬ 
tions,  sensors,  aircraft  (on  carrier  deck  or  ground),  and 
personnel.  Damage  from  multiple  or  successive  bursts  is  accu¬ 
mulated  by  one  of  three  methods  based  on  the  damage  mechanism 
associated  with  the  affected  operational  attribute.  The  avail¬ 
ability  of  each  operational  attribute  is  updated  based  on  the 
accumulated  damage.  The  ability  of  a  unit  to  successfully 
conduct  a  particular  mission  is  determined  by  the  combined 
availabilities  of  the  operational  attributes  required  for  that 
mission.  In  addition  to  calculating  damage  and  availability , 
NUCDAK  contains  an  algorithm  to  calculate  repair  time  delays  to 
determine  if  and  when  the  damage  will  be  corrected  in  the 
affected  capability  area.  The  data  flow  through  NUCDAM  is 
illustrated  in  Figure  2. 

NUCDAM  consists  of  a  main  driver  routine  which  is  called 
from  NNWS,  fifteen  subroutines  to  model  the  nuclear  effects, 
associated  auxiliary  subroutines.  NUCDAM  has  been  coded  in 
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FIGURE  2.  DATA  FLOW  THROUGH  NUCDAM 


FORTRAN  op  a  CDC  CYBER  720  at  KSC,  a  CDC  CYBER  730  at  Head- 
quarters  DNA,  a  VAX  at  NOSC,  in  PL/ 1  for  use  on  an  IBM  3033  at 
APL/JHU  by  CNO  (OP-654) ,  and  in  BASIC  for  use  on  a  TRS-80  system 
at  the  Naval  War  College, 

3 . 3  Nuclear  Environments 

The  nuclear  environments  calculated  by  NUCDAM  from  atmos¬ 
pheric  bursts  include  blast,  thermal,  EMP,  neutron  fluence  (1  MeV 
Si  equivalent),  total  ionizing  dose,  peak  gamma  dose  rate,  total 
x-ray  fluence,  and  tissue  ionizing  dose.  The  nuclear 
environments  from  underwater  bursts  include  peak  translational 
velocity,  excess  impulse,  energy  flux  density,  and  total  dose  and 
dose  rate  due  to  the  base  surge  produced  by  an  underwater  burst. 

3.4  Unit  OATs 

Each  OAT  represents  a  complex  assembly  of  many  component 
parts  which  has  some  functional  capability.  Seaworthiness  is  a 
measure  of  the  ship's  watertight  integrity,  including  the  ability 
to  survive  bad  weather  and  control  flooding.  For  submarines, 
seaworthiness  also  measures  the  ability  to  submerge,  adjust  depth 
and  surface  in  a  controlled  manner.  Mobility  measures  the  ship's 
ability  to  conduct  AAW,  ASW,  ASUW,  or  land  attack  engagements 
with  its  weapon  systems.  For  submarines,  weapon  delivery 
measures  the  ability  of  e  ship  to  launch  missiles,  torpedoes, 
SUBROC,  or  the  ASW/  SOW.  Communications  measures  the  ability  to 
transmit  and  receive  messages  from  other  units  afloat  or  ashore. 
Sensors  measures  the  ability  to  detect  and  track  other  ships  or 
aircraft,  or  to  direct  AAW,  ASW,  or  ASUW  engagements.  Aircraft 
measures  the  survivability  of  either  carrier-based  (as  a  weapon 
system  on  the  deck)  or  land-based  aircraft  and  crew.  KSC  is 
adding  a  module  to  handle  aircraft  in  flight.  Personnel  refers 
to  survivability  of  personnel  exposed  either  directly  or 
indirectly  to  nuclear  effects. 
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In  addition  to  the  ASW  and  ASUW  targets,  four  generic  types 
of  land  targets  are  included  in  NNWS.  They  consist  of  several 
common  OATs  as  well  as  one  or  more  OATs  specific  to  each  target 
type.  The  four  types  of  land  targets  are  naval  air  station, 
naval  bases,  naval  supply  centers,  and  ammunition  depots.  The 
common  OATs  include:  personnel,  administration  buildings,  POL 
dumps,  mechanical  handling  equipment,  piers,  and  storage 
facilities. 

OATs  specific  to  Naval  Air  Stations  include  aircraft  (also  a 
surface  ship  OAT) ,  runways,  hangers,  and  control  towers.  OATs 
specific  to  naval  bases  include  railroad  yards,  pumping  stations, 
and  heliports.  The  OATs  specific  to  ammunition  depots  are 
bunkers  ana  assembly  buildings.  Naval  supply  centers  have  no 
OATs  specific  to  themselves.  The  operational  attributes  that 
comprise  each  type  of  target  discussed  are  summarized  in  Table 
3-1. 

3.5  Damage  Environments 

Each  OAT  of  each  target  is,  in  general,  most  susceptible  to 
damage  from  a  particular  environment.  With  respect  to  underwater 
bursts,  there  is  little  information  available  for  the 
communication  and  sensor  OATs;  therefore,  these  two  OATs  were 
assumed  to  have  the  same  vulnerability  as  that  for  weapon 
delivery  since  the  most  vulnerable  component  for  weapon  delivery 
OAT  is  the  electronics,  either  sensors  or  fire-control  computers. 

With  respect  to  atmospheric  bursts,  there  is  considerable 
information  available  (both  theoretical  and  empirical)  on  damage 
to  surface  ships  and  their  associated  OATs.  As  such,  some  of  the 
surface  ships  OATs  may  be  susceptible  to  more  than  one 
environment  from  an  atmospheric  nuclear  burst.  For  instance,  a 
fire-control  radar  would  be  included  in  the  weapon  delivery  cate¬ 
gory.  The  radar  is  susceptible  to  mechanical  damage  from  air 


blast,  charring  or  scorching  of  the  radoroe  from  thermal  exposure, 
and/or  damage  to  internal  electronics  from  transient  radiation 
environments . 

For  land  targets  OATs,  air  blast  is  the  dominant  damage 
environment.  Structures,  functional)  groups,  aircraft,  and 
personnel  are  all  subject  to  damage  rom  the  overpressure  and/or 
dynamic  pressure  associated  with  the  blast  wave  from  a  nuclear 
weapon.  In  addition,  aircraft  and  personnel  may  be  damaged  by 
the  thermal  pulse,  and  personnel  are  susceptible  to  radiation. 

3.6  Damage  Model 

The  NUCDAM  damage  model  considers  the  weapon-target  geometry 
in  conjunction  with  specified  vulnerability  levels  to  calculate 
impairment  to  the  affected  OAT  from  intermediate  environment 
levels.  The  damage  model  considered  is  illustrated  in  Figure 
3.  Given  the  range  from  the  burst  to  the  target  and  the 
weapon/ target  characteristics,  the  environment  experienced  by  the 
target  is  calculated  as  shown  in  Figure  3a.  To  determine  the 
probability  of  weapon  system  impairment,  the  damage  or  impair¬ 
ment  curve  is  assumed  to  be  linear  between  the  vulnerability 
values  specified  for  10%  and  90%  impairment,  which  defines  a 
model  of  the  form: 

I  =  a  +  bE 

where  I  =  impairment  (0%  I  10%) 

a,b  =  constants  which  define  intercept  and  slope  of  the 
impairment  curve 
E  =  relevant  environment 

Therefore,  given  the  calculated  environment  the  probability  of 
damage  (or  impairment)  is  calculated  as  illustrated  in  Figure 
3b. 
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This  model  indicates  that  between  the  onset  of  damage  and 
complete  destruction,  incremental  increases  in  environment 
will  produce  corresponding  incremental  increases  in  impairment. 
This  damage  model  continues  to  be  used  in  NUCDAM  because  there  is 
no  hard  evidence  for  employing  any  other  model.  However,  there 
is  provision  in  NUCDAM  to  include  additional  types  of  damage 
models  as  data  becomes  available. 

3.7  Damage  Accumulation 

The  need  for  damage  accumulation  models  stems  from  the 
ability  of  nuclear  weapons  to  produce  damaging  environments  at 
long  ranges  from  the  detonation  point.  If  the  units  of  a  task 
group  are  spaced  far  enough  apart,  no  single  tactical  nuclear 
weapon  could  destroy  more  than  one  ship.  However,  the  damage 
producing  range  of  such  weapons  is  large  enough  that  a  unit  may 
incur  some  collateral  damage  as  a  result  of  an  attack  on  an 
adjacent  unit  in  the  task  group.  It  is  conceivable  that  a  unit 
could  be  damaged  to  the  point  of  combat  ineffectiveness  without 
it  ever  being  the  target  of  an  attack: 

These  methods  of  accumulating  damage  have  been  incorporated 
into  NUCDAM.  These  methods  are: 


o  Multiplicative  -  The  multiplicative  damage  model 
assumes  that  the  damage  levels  caused  by  successive 
detonations  are  statistically  independent.  The  proba¬ 
bility  of  survival  from  each  successive  detonation  are 
simply  multiplied  together  to  get  the  total  probability 
of  survival. 

o  Additive  -  The  additive  damage  model,  which  is 
primarily  based  on  structural  loading,  assumes  that 
damage  accumulates  linearly.  Total  deunage  is  the  sum 
of  impairments  produced  by  each  burst.  However,  based 
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on  test  data,  a  damage  increment  is  added  to  the  total 
damage  only  if  it  exceeds  65%  of  the  pre-existing  total 
damage. 

o  Maximum  -  The  maximum  damage  model,  which  is  based  on 
mechanical  or  electrical  component  damage,  assumes  that 
total  impairment  produced  by  a  series  of  bursts  will  be 
equal  to  the  greatest  impairment  that  exists  to  that 
point.  Whenever  a  burst  results  in  greater  damage  than 
already  exists,  the  accumulated  damage  increases  to  the 
new  level. 

One  or  another  of  the  damage  accumulation  models  is  assigned 
to  each  OAT  based  on  their  implied  function  and  the  nuclear 
environment  (s)  to  which  they  are  most  susceptible.  The  damage 
model  assignments  are  summarized  in  Table  1.  The  additive  model 
applies  to  the  seaworthiness  OAT  based  on  structural  damage  from 
blast/ shock  environments  and  to  any  other  OAT  that  is  vulnerable 
to  the  total  gamma  dose  radiation  environment.  The  maximum  model 
applies  to  the  mobility,  weapon  delivery,  communication,  and 
sensor  OATs  based  on  mechanical  component  damage  from  blast/shock 
environments  or  electrical  component  damage  from  the  gamma  dose 
rate  radiation  environment.  The  multiplicative  model  based  on 
the  statistical  damage  methodology  is  considered  to  be  more 
applicable  to  personnel  and  aircraft  OATs. 

3.8  Estimated  Time  To  Repair  (ETR)  Model 

When  a  target  is  damaged  by  a  nuclear  burst,  repair  of  the 
damaged  components  will  immediately  begin  in  an  attempt  to  restore 
as  much  as  possible  of  the  target's  original  functional 
capability.  Therefore,  the  impairment  of  a  target  OAT  will  be  a 
function  of  time,  starting  at  the  initial  level  of  impairment 
right  after  detonation  and  decreasing  as  time  passes  and  repairs 
are  made. 
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TABLE  1 

OAT  DAMAGE  ACCUMULATION  MODELS 


OAT 

ENVIRONMENT 

UNDERWATER 

SHOCK 

SUB  SURF 

— 

BLAST 

THERMAL 

RADIATION 

RATE  TOTAL 

SK 

Add 

Add 

Add 

—  , 

— 

MOB 

Max 

Max 

Max 

— 

— 

— 

WD 

Max 

Max 

Add 

Add 

Max 

Add 

Max 

Max 

Add 

Add 

Max 

Add 

SEiTS 

Max 

Max 

Add 

Add 

Max 

Add 

PERS 

Mult 

Mult 

Mult 

Mult 

Add 

Add 

A/C 

Muit 

Mult 

Mult 

Add 

The  ETR  model  employed  in  NUCDAM  is  based  on  several 
assumptions.  First,  the  ETR  model  ignores  the  fact  that 
identical  impairments  may  have  different  ETRs  and  indicates  that 
for  any  OAT,  the  ETR  is  a  direct  function  of  impairment.  Second, 
the  model  assumes  that  the  ETR  is  not  linear  with  impairment  but 
rather  exponential.  This  means  that  doubling  the  impairment  will 
square  the  repair  time,  which  implies  that  higher  levels  of 
impairment  will  generally  involve  more  serious  damage  to 
components  that  cure  less  easily  repaired  or  replaced.  Finally, 
it  is  assumed  that  above  a  certain  level  of  impairment  no  repair 
will  be  possible  unless  the  target  returns  to  port  in  the  case  of 
a  naval  vessel  or  reconstruction  begins  in  the  case  of  a  land 
target,  to  restore  the  target's  functional  capability. 


3.9  Vulnerability  Data 


Vulnerability  data  in  the  literature  generally  consist  of 
those  environmental  levels  which  will  produce  10%  to  90%  impair¬ 
ment  for  the  seaworthiness,  mobility,  and  weapon  delivery  OAT 
categories.  Data  also  are  available  for  the  severe,  moderate, 
and  light  damage  levels  related  to  the  aircraft  and  military 
equipment  categorizations.  These  damage  levels  have  been  assumed 
to  relate  to  90%,  50%,  and  10%  impairment,  respectively.  Other 
data  are  given  in  the  form  of  sure-safe  or  sure-kill  levels. 
These  levels  are  quantitatively  defined  as  0%  and  100% 
impairment.  The  vulnerability  data  is  used  in  the  damage  model 
to  describe  the  shape  of  the  impairment  curve  when  calculating 
damage  from  some  intermediate  level  of  environment. 

3.10  Vulnerability  Tables 

The  vulnerability  data  used  for  underwater  and  atmospheric 
burst  effects  on  submarines,  surface  ships,  and  land  targets  were 
combined  with  the  operational  attributes,  nuclear  environments, 
damage  and  repair  models  to  produce  a  data  base  to  be  utilized  by 


NUCDAM.  In  order  to  determine  weapon  system  impairment  and  ETR 
for  a  target  subjected  to  a  nuclear  burst,  NUCDAM  accesses  the 
necessary  data  from  the  vulnerability  table.  The  vulnerability 
table  contains  the  following  entries: 

o  An  index  which  allows  access  of  the  appropriate  data 
for  the  affected  OAT. 

o  An  alphanumeric  description  of  the  OAT  categories. 

o  An  index  indicating  which  nuclear  environment 
subroutine  to  use. 

o  An  index  indicating  which  damage  model  to  use 

(currently,  only  a  linear  model  is  available  in  the 
code) . 

o  Vulnerability  data  corresponding  to  10%  and  90% 

impairment  for  calculating  intermediate  levels  of 
impairment  in  the  damage  model. 

o  An  index  indicating  which  damage  accumulation  model  to 
use  (1  =  multiplicative,  2  =  additive,  3  =  maximum) . 

o  An  index  indicating  which  ETR  model  to  use  (currently 
only  an  exponential  model  is  available  in  the  code) . 

o  The  values  required  to  calculate  the  ETR  based  on  the 
level  of  impairment. 

Vulnerability  tables  have  been  created  for  each  of  the 
submarine,  surface  ship,  and  land  target  categories.  The 

vulnerability  of  any  class  of  target  can  be  completely 
characterized  by  combining  the  appropriate  OATs  for  each  target 
type  with  the  nuclear  environments  and  vulnerability  data 
described  earlier. 


4.0  CONFIGURATION  MANAGEMENT  PLAN  A U'-)  PROCEDURES 


Configuration  management  for  the  OP-654  sponsored  Nuclear 
Damage  Assessment  Module,  shall  involve  the  establishment  and 
maintenance  of  a  formal  plan  and  ^et  of  procedures  by  which 
design  control,  development,  modification  scheduling,  and  status 
accounting  may  be  accomplished  under  the  -uthority  of  OP-654. 

The  Configuration  Management  Plan  and  Procedures  herein 
specified  shall  be  simple  in  concept,  organization,  and  imple¬ 
mentation.  However,  they  shall  also  be  malleable  so  that  as  a 
system  evolves  and  expands,  the  plan  and  procedures  shall  be 
capable  of  accommodating  more  complexities  without  basic 
redesign.  It  is  to  be  emphasized  that  the  plan  and  procedures 
are  not  to  impose  a  burden  on  the  developers  or  users.  Rather, 
they  shall  enhance  the  operating  processes  by  keeping  all 
interested  parties  up-to-date  respecting  the  status  of  the 
system. 

The  Configuration  Management  Plan  which  identifies  and 
specifies  management,  identification,  control,  and  maintenance 
for  a  system  under  configuration  control. 

It  is  anticipated  that  the  procedures  for  configuration 
management  functions  will  evolve.  To  accommodate  this  dynamic 
environment,  this  document  and  its  updates  shall  be  controlled 
within  the  configuration  management  plan  similar  to  any  other 
software  product.  The  initial  promulgation  of  this  document 
shall  represent  its  baseline,  and  changes  to  the  document  will  be 
accomplished  with  the  procedures  identified  for  changing  any 
baselined  item. 


4.1  Objective  and  Scope 


The  objective  of  Configuration  Management  (CM)  for 
Simulations  and  Management  Information  Systems  is  to  establish 
and  maintain  a  formal  set  of  procedures  by  which  a  uniform  system 
of  identification,  design  control,  and  modification  scheduling 
may  be  accomplished.  Configuration  management  is  concerned  with 
the  total  activities  of  the  system;  the  development, 
implementation,  testing,  verification,  and  operation  of 
individual  subsystems. 

Specifically,  configuration  management  shall  aid  in 
preserving  the  integrity  of  the  system.  It  shr.ll  assure  that 
replication  of  data,  programs,  and  input  procedures  does  not 
exist;  that  the  interfacing  routines  interact  in  a  compatible 
manner;  that  the  data  base  structures  remain  stable;  that 
adequate  advance  coordination  is  provided  to  all  users  concerned 
with  any  changes;  that  such  changes  are  tested  and  verified  prior 
to  release;  and  that  the  structure  and  content  of  the  system  is 
protected  by  proper  security  measures. 

The  scope  of  configuration  management  shall  be  defined  in 
terms  of  the  following  activities: 

o  Configuration  Identification  -  The  configuration  of  the 
system  shall  be  identified  by  and  documented  in  a 
series  of  manuals,  and  computer  printouts. 

o  Configuration  Control  -  In  the  configuration  control 
process,  chaises  to  the  established  manuals  shall  be 
initiated,  revxewed  and  evaluated,  approved  or 
rejectee,  implemented  and  verified,  and  released. 
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The  purpose  is  to  assure  that  the  configuration  used  in 
critical  phases  of  testing,  acceptance,  delivery,  and 
operational  life  tijne  is  known  as  compatible  with  the 
specifications . 

o  Configuration  Maintenance  -  Configuration  Maintenance 
is  the  process  by  which  the  software  and  documentation 
are  supported  in  order  to  be  up  to  date  and  usable  and 
by  which  end  items  and  changes  to  end  items  are  pre¬ 
pared  for  release. 

o  Configuration  Processing  -  Configuration  processing  is 
the  means  by  which  the  configuration  management 
procedures  are  implemented  and  maintained  and  whereby 
the  software  end  items  and  products  are  stored  and 
distributed. 

Concurrent  with  these  activities,  configuration  reviews  and 
audits  during  the  development  cycle  shall  provide  verification 
that  the  performance  achieved  by  the  end  item  is  the  performance 
required  by  the  specification  and  that  the  configuration  of  the 
end  item  is  accurately  specified. 

4.1.1  Document  Organization 

This  document  defines  the  organization  and  procedures  for 
configuration  management.  The  following  paragraphs  present  an 
overview  of  this  document. 


The  Configuration  Management  Office  (CMO,  OP-654) ,  shall  be 
responsible  for  establishing,  organizing,  and  maintaining  the 
configuration  management  and  control  operation.  Section  4.2 
discusses  the  configuration  management  organization,  and  the  CMO 
functions . 

The  CMO  shall  be  responsible  for  identifying  the  configura¬ 
tion  which  shall  form  the  basis  for  change  control  and  status 
accounting  functions.  Section  4.3  discusses  configuration 
identification  and  baseline  definition  and  requirements. 
Included  are  the  forms  to  be  used  to  release  and  to  propose 
changes  to  an  identified  configuration. 

The  CMO  shall  form  the  Configuration  Control  Board  (CCB)  as 
a  body  representing  the  organizations  and  individual  users  cf  the 
controlled  system  and  other  technically  cognizant  personnel. 
Section  4.4  discusses  the  meaning  of  configuration  control,  the 
CCB  functions  as  they  relate  to  the  controlled  items. 

The  CMO  shall  designate  the  Configuration  Maintenance  Group 
(CMG)  as  technically  qualified  personnel  oriented  toward  operat¬ 
ing,  updating,  and  maintaining  software  subsystems  and  associated 
documentation.  The  CMG  will  generally  be  from  organizations 
responsible  for  maintenance  of  subsystems  and  fxom  organizations 
developing  subsystems.  Section  4.5  discusses  the  meaning  of 
controlled  items. 

The  CMO  shall  establish  the  Configuration  Control  Center 
(CCC)  as  a  body  responsible  for  communicating  and  interfacing 
with  the  users,  the  CCB,  and  the  CMG  for  maintaining  a  central 
repository  of  information  and  software  products.  Section  4.6 
discusses  the  functions  of  CCC  as  they  relate  to  the  controlled 
items . 
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4.2  Configuration  Management  Organization 

Configuration  management  responsibilities  consist  of  exer¬ 
cising  baseline  and  change  approval  authority ,  maintaining 
functions.  These  responsibilities  shall  be  shared  by  OP-654  and 
designated  cognizant  contractors  until  such  time  as  OP-654  wishes 
to  assume  full  management  and  control  functions. 

The  basic  responsibilities  of  the  configuration  management 
function  shall  be  as  follows: 

o  Implement  configuration  change  control  procedures 
immediately  upon  establishment  of  the  baseline. 

o  Insure  chat  proposed  changes  to  end  items  and/or 

documents  are  documented  in  detail  on  applicable  change 
request  forms  prior  to  review,  evaluation,  and/or 
initiation  of  implementation. 

o  Insure  that  documented  change  requests  are  reviewed, 

evaluated  and  approved  prior  to  implementation;  and 
that  rejected  change  re<~'°-sts  are  omitted  from  the 
implementation  cycle. 

o  Insure  effective  and  efficient  operation  of  the  change 
control  cycle  to  the  extent  that  no  changes  are 
implemented  without  prior  approval,  and  no  unnecessary 
delays  are  experienced  in  the  processing  of  a  change 
request. 

o  Update  and  release  the  modified  system  at  an  appro¬ 
priate  time  and  insure  that  updated  documentation 
accompanies  the  release. 


4.2.1  Configuration  Management  Office  (CMO)  Function 

The  Configuration  Management  Office  (CMO)  shall  be 
responsible  for  establishing,  organizing,  and  maintaining  the 
configuration  management  and  control  operation.  The  CMO  shall  be 
responsible  for  establishing  and  directing  the  configuration 
management  functions.  It  will  authorize  activities  and  have 
ultimate  approval  over  the  configured  system,  proposed  modifi¬ 
cations,  and  support  documentation. 

4.3  Configuration  Identification 

The  configuration  as  identified  by  OP-654  shall  be  defined 
as  the  basis  for  the  change  control  functions.  The  initiation 
point  for  software  configuration  management  shall  be  the 
baseline.  For  developmental  subsystems  this  is  established  by 
review  and  acceptance  of  description  or  specification  documents. 
For  existing  subsystems  the  baseline  may  be  defined  as  the 
current  configuration  and  documents. 

After  a  defined  baseline  item  has  been  accepted,  changes  may 
be  proposed  using  the  form  created  for  this  purpose.  Subsequent 
sections  depict  and  describe  the  forms  and  list  the  items  to  be 
maintained  under  configuration  control. 

4.3.1  Baseline  Definition  and  Requirements 

Baselines  are  defined  because  they  are  the  basis,  or 
reference  points,  for  subsequent  development  and  control. 
Baselining  a  subsystem  requires  that  the  physical  and  functional 
characteristics  of  the  controlled  subsystem  end  items  and 
products  be  defined  and  documented  at  a  logical  transition  point 
in  the  system  life  cycle. 


The  milestone  defined  for  configuration  management 
initiation  for  systems  or  subsystems  being  developed  shall  be  the 
baseline  established  at  the  Critical  Design  Reviews  (CDRs) .  The 
subsystem  design  and  implementation  processes  are  illustrated  in 
Figure  4.  Certain  tasks  shall  be  performed  and  pertinent  docu¬ 
mentation  shall  be  generated  to  reflect  an  accurate  description 
of  the  baselined  configurations.  These  tasks  and  documents  are: 

o  The  acceptance  of  a  task  order  proposal  (at  a  Proposal 
Review)  leads  to  a  decision  to  implement  the  subsystem. 
At  the  proposal  review  a  unique  identification  is 
assigned  to  the  subsystem,  and  this  identification  will 
accompany  all  software  products  and  manuals  for  the 
lifetime  of  the  subsystem. 

o  The  acceptance  of  a  Preliminary  Design  Description 
(PDD)  document  (following  a  Preliminary  Design  Review 
(PDK) )  leads  to  a  decision  to  develop  subsystem  speci¬ 
fication.  Design  modifications  requested  at  the  PDR 
are  incorporated  into  the  PDD. 

o  The  acceptance  of  a  SCP  following  the  CDR  leads  to  a 
decision  to  develop  the  subsystem  and  establishes  the 
SCP  as  the  subsystem  design  specification  document. 
The  Subsystem  Design  Specification  document  identifies 
the  baseline  for  that  subsystem.  Design  modifications 
requested  at  the  CDR  are  incorporated  into  the  docu¬ 
ment. 

o  The  Subsystem  Design  Specification  document  details  the 
subsystem  environment  and  design  elements  required  for 
computer  program  and  data  base  implementation.  It 
includes  subsystem  specifications,  functions,  input  and 
output  requirements,  flow  charts,  and  performance 
requirements.  It  describes  the  program  development  and 
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production  control.  The  document  provides  the  basic 
design  data  necessary  for  construction  of  subsystem 
procedures,  forms,  files,  tables,  and  dictionaries.  It 
describes  the  storage  allocation  and  data  base  organi¬ 
zation.  It  includes  specifications  for  implementation, 
testing,  and  verification  criteria. 

o  The  acceptance  of  the  Final  Design  Description  document 
at  the  Operational  Design  Review  (ODR)  leads  to  the 
acceptance  of  an  operational  subsystem. 

The  Final  Design  Description  document  presents  a 
description  of  the  subsystem's  logical  and  physical 
architecture  including  procedures,  forms,  programs,  and 
data  bases.  It  indicates  what  the  subsystem  is 
designed  to  accomplish  and,  in  general,  how  the  design 
shall  be  implemented.  It  covers  operating  procedures, 
overall  subsystem  methodology  and  related  hardware 
configuration.  It  describes  the  subsystem  for  the 
individual  interested  in  an  overview  of  subsystem 
design  and  operations. 

o  At  subsystem  acceptance  the  Users,  Programmers  and 
Data  Base  Manuals,  as  required,  become  effective.  An 
orientation  for  the  users  and  programmers  is  conducted 
to  acquaint:  them  with  the  subsystem  and  the  use  of  the 
manuals. 

The  User's  Manual  describes  system  operation  at  the 
user  level  including  man-system  interaction,  data 
requirements  and  system  products.  It  defines  alpha¬ 
numeric  and  graphic  display  formats  and  the  structure 
of  user  actions.  It  describes  system  elements  and 
their  operational  attributes.  The  User’s  Manual 
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describes  the  system  capabilities,  inputs,  and  out¬ 
puts.  It  defines  the  input  and  output  options,  data 
elements,  file  structures.  It  also  contains  examples 
of  deck  set-ups,  inputs,  and  outputs  as  required. 

The  Programmers  Manual  describes  in  detail  all 
system  software.  It  includes  the  current  approved  flow 
charts  along  with  explanations  and  listing  of  the 
environment  and  impairment  routines  used  by  the  NUCDAM 
code.  It  documents  all  physical  and  functional 
interfaces  between  the  subsystems.  It  contains  a 
catalog  of  all  modules  or  subroutines  with  their 
effective  date,  i.e.,  the  date  of  the  last  modification 
or  compilation. 

The  Data  Base  Manual  contains  data  elements  information 
about  the  necessary  vulnerability  data  used  by  NUCDAM. 
It  defines  each  data  element,  identifies  the  sources, 
indicates  the  uses,  and  not.es  applicable  security 
restrictions.  It  contains  other  pertinent  information 
to  be  determined. 

4.3.2  System  Change  Proposal  (SCP)  Form  Description 

This  form,  depicted  in  Figure  5,  shall  be  used  by  anyone 
wishing  to  propose  a  change  to  software,  documentation,  or 
procedures  because  of  a  problem,  a  specification  change,  or  an 
improved  implementation  technique. 

4.3.3  Change  and  Release  (CAR)  Form  Description 

This  form,  depicted  by  Figure  6,  shall  be  used  by  anyone 
wishing  to  release  a  software  product  or  document  to  OP-654  and 
by  OP-654  when  ar.  end  item  is  to  be  released  for  use.  Initially, 
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SYSTEM  CHANGE  PROPOSAL  FORM  (SCP) 


_ 1.  SCP  No. 

2.  Title  _ 

4.  Subsystem  Name  _ 

6.  Implemented  by  _ 

7.  Verified  by  _ 

8.  Released  by  _ 

12.  CAR  No.  References 


13.  Items  Affected: 

Subsystems  _ 

JCL  _ 

Program/Modules 

Data  Files  _ 

Documents  _ 

Other 


14.  Description  of  Implementation ,  Verification,  and  Rel 
(All  items  affected  shall  be  described.) 


3.  Date  _ 

5.  ID  _ 

9  App.  by 

10.  App.  Date 

11.  Eff.  Date 


15.  Reason  for  Change 


16.  Evaluation 


17.  CCB  Action 


18*  CCB  Attendees 


SYSTEM  CHANGE  PROPOSAL  FORM  (SCP) 


_ 1.  CAR  No. 

2.  Title  _ 

4.  Subsystem  Name 

6.  Implemented  by  _ 

7.  Verified  by  _ 

8.  Released  by  _ 

12.  SCP  No.  References 


13.  Items  Affected: 

Subsystems  _ 

JCL _ 

Program/Modules 

Data  Files  _ 

Documents  _ 

Other  _ 


14.  Description  of  Implementation,  Verification,  and  Release 
(All  items  affected  shall  be  described.) 


3.  Date  _ 

5.  ID  _ 

9  App.  by  _ 

10.  App.  Date 

11.  Eff.  Date 


OP-654  shall  use  it  to  release  a  subsystem  and  supporting  docu¬ 
ments  to  the  system  users.  After  verification  of  subsystem 
modifications  as  developed  for  a  SCP ,  the  CAR  shall  be  used  to 
convey  to  OP-654  tne  software  products,  cards,  tables,  listings, 
test  results,  and  documentation  resulting  from  the  change.  When 
a  new  or  revised  version  of  a  system  end  item  is  released,  a  CAR 
shall  be  used  to  document  and  convey  this  information. 

4.3.4  Controlled  Items 

As  a  minimum,  the  following  items  shall  be  placed  under 
configuration  control  after  baselining  has  occurred. 

o  Subsystem  Software  Products  -  Each  subsystem  shall  be 
controlled.  The  software  products  accompanying  the 
release  shall  include  the  original  source  deck;  the 
modification  deck  unless  a  new  source  is  produced;  the 
disk  files  -  source,  object,  and  load;  the  tape  files  - 
source,  object,  and  load;  and  the  program  listings. 

o  Subsystem  Design  Specification  Document  -  Upon 

subsystem  baseline,  this  document  shall  be  released  ror 
control. 

o  Final  Design  Description  Docurent  -  Upon  acceptance  of 
the  operational  subsystem,  this  document  shall  be 
released  for  control. 

o  Programmers  Manual  -  Upon  acceptance  of  the  operational 
subsystem,  this  document  shall  accompany  the  system 
release.  It  shall  be  updated  with  each  system  update. 
The  modified  pages  shall  be  distributed.  At  selected 
times  the  entire  document  shall  be  reissued. 
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o  User  Manual  -  Upon  acceptance  of  the  operational 
subsystem,  this  document  shall  accompany  the  system 
release.  It  shall  be  updated  with  each  system  update. 
The  modified  pages  shall  be  distributed.  At  selected 
times,  the  entire  document  shall  be  reissued. 

o  Data  Base  Manual  -  Upon  acceptance  of  the  operational 
subsystem,  this  file  and  associated  document  shall 
accompany  the  system  release.  They  shall  be  updated 
with  each  subsequent  applicable  system  release. 

o  Access  Control  Document  -  This  document  shall  be  main¬ 
tained  by  OP-654.  It  includes  the  subsystem (s)  account 
number,  user  initials,  keywords,  and  other  means  of 
access  to  the  subsystem (s)  files  with  the  list  of 
personnel  who  have  access  and/or  update  privileges. 
The  CMO  shall  determine  this  personnel  list. 

4.4  Configuration  Control 

Configuration  control  is  defined  as  the  process  by  which 
changes  to  end  items  and  documents  are  initiated,  reviewed  and 
evaluated,  approved  or  rejected,  implemented  and  verified,  and 
released.  When  an  end  item  or  document  master  is  released  to  the 
CMO,  it  shall  not  be  changed  until  the  requested  change  has  been 
approved  by  the  Configuration  Control  Board  (CCB) . 

The  Configuration  Control  Board  (CCB)  shall  be  established 
by  OP-654  to  assume  these  responsibilities. 

4.4.1  Configuration  Control  Board  (CCB)  Function 

The  function  of  the  CCB  is  to  represent  and  be  technically 
cognizant  of  the  requirements  of  the  organizations  and  indivi¬ 
dual  users  of  the  system,  to  assist  in  baselining  an  end  item,  to 
evaluate  and  approve  change  requests,  and  to  monitor  the  config¬ 
uration. 
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The  CCB  functions  shall  include  the  following: 

o  Represent  the  various  organizations  and  individual 
users  of  the  system  and  be  technically  cognizant  of 
their  requirements  so  that  by  representing  a  system 
point  of  view,  it  may  minimize  duplication  of  effort 
among  subsystems,  insure  subsystem  compatibility,  and 
assure  that  subsystem  development,  documentation, 
testing,  verification,  and  operation  follow  a 
consistent  set  of  standards. 

o  Assist  in  baseline  identification  by  reviewing  the 
Subsystem  Design  Specification  and  Final  Design 
Description  documents  to  familiarize  themselves  with 
the  subsystem  being  developed;  to  participa .  _  in  the 
design  reviews,  (at  a  minimum  the  Critical  and 
Operation  Design  Reviews)  to  insure  that  the  sub¬ 
system  meets  its  design  specifications;  and  to  review 
the  User,  Programmers  and  Data  Base  Manuals  to  insure 
that  the  baseline  configuration  is  adequately  and 
appropriately  documented. 

o  Review,  evaluate,  approve  or  reject  proposed  changes  to 
the  subsystem  and/or  its  documentation.  Consideration 
shall  be  given  to  the  desirability  of  the  change  and 
benefits  to  the  current  subsystem;  its  impact  on 
current  and  potential  users  and  on  other  subsystems,  on 
current  implementation ,  schedules,  and  cost;  its 

administrative  or  technical  necessity;  and  feasible 
alternatives  such  as  adopting  a  workaround  procedure  if 
the  change  were  not  approved.  The  CCB  shall  recommend 
to  OP-654  the  approval,  rejection,  or  alternate 
approach  to  the  proposed  changes. 


o 


Monitor  the  configuration  by  coordination  with  the  CMG 
(Configuration  Maintenance  Group)  to  insure  that  the 
changes  are  designed,  implemented,  tested,  and  verified 
as  specified  and  that  the  updated  subsystems  are 
released  according  to  schedule. 

The  CCB  shall  schedule  periodic  reviews  as  required  to 
examine  the  design  and  implementation  methods  during  the  develop¬ 
ment  of  modification  period.  Upon  approval,  the  CMG  will 
proceed;  otherwise,  redesign  and  rework  shall  ensue.  After 
completion  and  verification  of  the  change,  the  CCB  may  review  the 
final  implementation  and  make  recommendations  to  the  CMO 
(OP-654) . 

4.5  Configuration  Maintenance 

Configuration  maintenance  is  the  process  by  which  the 
software  and  documentation  are  supported  in  order  to  be  up-to- 
date  and  usable  and  by  which  end  items  and  changes  to  end  items 
are  prepared  for  release.  This  process  begins  after  the  CMO  and 
CCB  have  approved  a  baseline  or  a  change  and  continues  for  the 
lifetime  of  the  subsystem.  The  preparation  for  release  will  be 
initiated  with  OP-654  approval  and  will  cause  the  released  soft¬ 
ware  to  become  available  as  of  the  date  specified. 

The  responsibilities  of  the  configuration  maintenance 
function  to  be  undertaken  by  the  Configuration  Maintenance  Group 
(CMG)  are  as  follows: 

o  Maintain  the  configuration  within  the  current  operating 
system  so  that  it  is  accessible  for  use  only  by  select 
users  and  that  it  is  accessible  for  modification  only 
by  authorized  personnel  with  approval. 


o  Update  the  configuration  as  specified  by  the  SCPs  which 
are  approved  by  OP-654. 

o  Support  backup  capabilities  as  defined  by  OP-654. 

4.5.1  Configuration  Maintenance  Groups  (CMG)  Function 

The  function  of  a  CMG  is  to  implement  and  verify  the 

software  end  item  as  approved  and  released  by  CMO  and  to 

coordinate  documentation  updates  with  subsystem  configuration 
updates. 

The  CMG  functions  include  the  following: 

o  Accomplish,  verify,  and  implement  the  changes  and 

modifications  as  documented  by  approved  SCPs.  The 
documentation  such  as  the  Subsystem  Design  Specifi¬ 
cation  and  Final  Description  documents,  the  Users, 
Programmers,  and  Data  Base  Manuals,  shall  be  updated  to 
reflect  the  modifications.  All  changes  shall  be 

conveyed  to  the  CCC  via  the  CARs. 

o  If  after  subsystem  delivery  another  CMG  is  responsi¬ 
ble  for  subsystem  operation,  verification  of  opera¬ 
tion  may  be  deemed  desirable.  This  may  be  achieved  by 
rerunning  the  test  cases  and  verifying  the  test  results 
or  it  may  require  the  development  of  new  or  additional 
test  cases  and  criteria.  After  verification  and 
acceptance,  the  CMG  shall  update  the  subsystem 
programs,  JCL,  and  data  files  to  become  effective 
release  data  established  by  the  CMO. 

o  Execute  production  programs  as  may  be  requested  by  the 
CMO  and  other  organizations. 


o 


Maintain  the  operating  procedures ,  and  other  systea 
Maintenance  functions.  This  function  entails  insuring 
that  backup  cards  and/or  tapes  exist,  are  current,  and 
be  made  available  to  CCC  for  safe  storage. 

4.6  Configuration  Processing 

Configuration  processing  is  the  Means  by  which  the  configura¬ 
tion  Manageaent  procedures  are  iapleMented  and  Maintained  and 
whereby  the  software  end  itews  and  products  are  stored  and 
distributed.  The  basic  responsibilities  include  ccMMunicating 
and  interfacing  with  the  users,  and  the  CMGs;  the  storage  and 
distribution  of  software  products  and  intonation;  and  the  status 
accounting  of  the  configurations  under  control. 

The  Configuration  Control  Center  (CCC)  will  accowpiish  these 
responsibilities . 

4.6.1  Configuration  Control  Center  (CCC)  Function 

The  function  of  the  CCC  is  to  iwplesKtnt  and  Maintain  the 
configuration  control  procedures  and  act  as  a  central  repository 
of  information  and  central  coMMunic a tions  facility. 

o  Act  as  the  central  contact  point  for  procedural 
activities  related  to  Managing  the  configurations 
assisting  the  CMO  in  arranging  Meetings  for  the  CCB, 
CMC,  users,  and  other  auxilliary  personnel  to  review 
the  proposed  changes.  The  CCC  shall  prepare  a  review 
package  and  be  prepared  to  discuss  the  status  of 


The  CCC  will  provide  update  release  information, 
software  products,  and  documents  as  required  to 
interested  authorized  recipients;  prepare  and  distri¬ 
bute  minutes  of  configuration  review  meetings;  and 
handle  and  process  the  CARs  and  SCPs. 

Assure  the  configuration  identification  of  the  sub¬ 
system  immediately  upon  the  initiation  of  the  baseline 
and  assign  identification  numbers  to  the  software 
documents  and  products. 

The  identification  number  assigned  to  a  subsystem  is 
that  agreed  to  at  the  proposal  review.  It  shall  be 
unique  in  that  it  does  not  duplicate  the  identifi¬ 
cation  assigned  to  any  other  subsystem. 

Accept  responsibility  for  storage  and  distribution  of 
software  documents  and  products.  This  entails  being 
the  central  repository  for  up-to-date  software 
documents  and  products  and  insuring  that  duplicate 
masters  of  computer  programs  and  documentation  are 
maintained  in  a  remote  location. 

The  Data  Base  Manual  for  data  element  definitions  used 
in  the  controlled  systems  will  be  maintained  by  the 
CCC. 

Accomplish  status  accounting.  This  requires 
maintaining  a  log  of  all  change  requests  and  the  status 
of  their  processing,  and  preparing,  maintaining,  and 
distributing  status  reports  as  required  to  provide 
adequate  visibility  of  the  configurations  and 
configuration  management  activities  in  process. 


5.0  VERSION  IDENTIFICATION  AND  CONTROL 


For  the  purpose  of  control  and  identification  each  imple¬ 
mentation  of  NUCDAM  will  be  identified  as  a  version.  All  of  the 
versions  use  the  same  models  but  are  different  in  their  imple¬ 
mentation  . 


NUCDAM  VERSION  #1 


PHASE  III 
IBM  3033 
PL1 

NNWS  (OP-654) ,  APL,  Johns-Hopkins  Oniv. 

Notes : 


Developed  From: 
Computer: 

Language : 

Current  Distribution: 


NUCDAM  was  developed  by  Kaman  Sciences  Corporation  for 
OP-654 ,  to  be  used  in  NNWS  for  calculating  damage  to  naval  units 
involved  in  tactical  nuclear  engagements  at  sea.  Each  time  a 
nuclear  burst  occurs  in  a  naval  warfare  engagement ,  NUCDAM  is 
called  by  the  NNWS  Executive  Routine  with  sufficient  input  data 
to  perform  the  damage  assessment  function.  The  inputs  to  NUCDAM 
consist  of  target  parameters  carried  in  the  unit  state  vector , 
weapon  parameters  which  are  passed  from  the  Executive  Routine, 
and  the  environment  vulnerability  data  for  the  particular  unit 
type  from  the  vulnerability  tables  contained  in  the  data  base. 
These  data  describe  the  target  operational  attributes,  the 
current  operational  attribute  availability  and  repair  completion 
time  status,  and  the  damage  and  repair  time  model  threshold  para¬ 
meters.  The  impairment  and  repair  time  calculations  are  then 
made  in  NUCDAM  for  each  of  the  operational  attributes  that 
describe  the  unit  being  evaluated.  The  output  from  NUCLAIi 
consists  of  updates  to  the  availability  and  repair  completion 
time  parameters  for  each  operational  attribute  carried  in  the 
unit  state  vector.  After  the  damage  calculations  and  parameter 
updates  are  completed  for  this  particular  engagement,  control  is 
passed  back  to  the  Executive  Routine  to  determine  the  unit’s 
capability  to  perform  its  mission. 
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NUCDAM  VERSION  #2 


Developed  From:  PHASE  II 

Computer:  Radio  Shack  TRS-80  Model  1  Microcomputer 

Language :  FORTRAN 

Current  Distribution:  Naval  War  College 

DNA,  LASL  (CDC  CYBER) 

Kaman  Sciences  Coloration 


Notes : 

Kaman  Sciences  Corporation  has  implemented  the  Phase  II 
NUCDAM  program  on  a  Radio  Shack  TRS-80  microcomputer  using  the 
TRS-80  Fortran  Package  by  Microsoft  Consumer  Products.  The  im¬ 
plementation  includes  a  single  interactive  driver  program  which 
replaces  the  NNWS  Executive  Routine.  This  allows  the  user  to 
specify  the  inputs  to  subroutine  NUCDAM.  Provisions  have  been 
made  to  allow  inputs  from  the  keyboard  or  from  the  disk.  Outputs 
from  NUCDAM  are  sent  to  the  line  printer  by  the  driver  routine. 
This  version  of  NUCDAM  provides  the  user  with  a  simple  means  of 
examining  the  effects  of  nuclear  weapons  on  a  ship. 

In  order  to  implement  NUCDAM  on  a  microcomputer,  the  data 
structure  has  been  reduced.  The  TRS-80  implementation  processes 
one  unit  at  a  time,  with  that  unit  defined  by  up  to  ten  opera¬ 
tional  attributes.  TRS-80  NUCDAM  occupies  about  32K  bytes  out  of 
a  maximum  of  48K  bytes  available.  Execution  time  requires  only  a 
few  seconds  for  a  unit  with  10  OATs. 

The  delivered  TRS-80  NUCDAM  includes  the  unclassified 
version  of  subroutine  RADENV,  with  dummy  values  for  certain 
coefficients.  Prompt  radiation  environments  are  therefore  mean¬ 
ingless  until  required  changes  are  applied  to  produce  the 
classified  version  of  RADENV.  In  addition,  this  version  of 
NUCDAM  does  not  include  the  additional  nuclear  weapon  effects 


39 


incorporated  under  Phase  III.  These  additional  nuclear  weapon 
effects  from  underwater  bursts  included  the  blast  overpressure 
along  the  surface  of  the  water  <psi) ,  the  peak  dose  rate  from  the 
base  surge  (Rads/Hr) ,  the  total  dose  from  the  base  surge  (Rads) , 
and  the  peak  translational  velocity  (ft/sec)  which  include  the 
effects  of  bottom  ret lection. 
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NUCDAM  VERSION  #3 


Developed  From:  ?HASE  II 

Computer:  WANG  2200  T/VP 

Language:  BASIC 

Current  Distribution:  Naval  Weapons  Training  Group  (LANT&PAC) 

Naval  Tactical  Support  Activity  (FMPL) 
Commander  Second  Fleet 
Kaman  Sciences  Corporation 

Notes: 

NUCDAM  has  been  implemented  on  the  WANG  2200  T&VP 
microcomputers.  The  WANG  implementation  of  NUCDAM  is  a 
translation  into  BASIC  of  the  TRS-80  microcomputer  version  of 
NUCDAM,  which  was  written  in  FORTRAN.  The  TRS-80  version  is  in 
turn  based  upon  the  NNWS  Phase  II  NUCDAM  code.  The  NUCDAM 
Version  #3  code  is  written  in  WANG  BASIC  2.0.  The  program  is 
supplied  on  a  single-sided,  single-density  eight  inch  disk. 
NUCDAM  and  associated  data  files  occupy  122  out  of  1023  sectors. 
Execution  is  performed  by  resetting  the  computer,  inserting  the 
NUCDAM  disk  in  the  proper  drive,  and  entering  the  appropriate 
commands . 

The  WANG/NUCDAM  includes  the  unclassified  version  of  sub¬ 
routine  RADENV ,  with  dummy  values  for  certain  coefficients. 
Prompt  radiation  environments  are  therefore  meaningless  until 
required  changes  are  applied  to  produce  the  classified  version  of 
RADENV.  In  addition,  this  version  of  NUCDAM  does  not  include  the 
additional  nuclear  weapon  effects  incorporated  under  Phase  III. 
These  additional  nuclear  weapon  effects  from  underwater  bursts 
included  the  blast  overpressure  along  the  surface  of  the  water 
(psi) ,  the  peak  dose  rate  from  the  base  surge  ( Rad/Hr) ,  the  total 
dose  from  the  base  surge  (Rads)  ,  and  the  peak  translational 
velocity  (ft/sec)  which  included  the  effects  of  bottom 
reflection. 


NUCDAM  VERSION  #4 


Developed  From: 
Computer: 

Language: 

Current  Distribution: 


PHASE  II 

HP9845 

BASIC 

Tactical  Training  Group  (LANTfcPAC) 
Commander  Second  Fleet 
Raman  Sciences  Corporation 


Notes: 

Raman  Sciences  Corporation  has  implemented  the  Phase  II 
NUCDAM  on  the  HP9845  microcomputer .  Two  versions  of  NUCDAM  have 
been  developed  for  the  HP9845  microcomputer ,  called  the  Fleet 
Model  and  the  Analytic  Model. 

The  Fleet  Model  is  designed  for  maximum  efficiency  and  ease 
of  operation.  Demands  for  user  selection  of  variable  inputs  have 
been  minimized.  Target  data  are  taken  from  input  files  which 
have  been  pre-loaded  into  the  memory  along  with  the  main  program 
for  U.S.  and  Soviet  surface  ships,  carrier,  and  submarines. 
Nevertheless,  provisions  exist  for  the  user  to  override  these 
data  and  furnish  his  own,  should  this  become  necessary.  Techni¬ 
cal  data  have  been  cut  to  a  minimum  to  avoid  distracting  or 
confusing  the  users  interested  only  in  the  bottom  line.  Thus, 
the  output  of  this  model  contains  verbal  descriptions  of  plat¬ 
form  damage  rather  than  tables  of  data. 

The  Analytical  Model  presents  all  of  the  input  and  output 
data  available  in  NUCDAM  and  allows  the  user  complete  freedom  to 
modify  them  as  necessary.  The  user  has  the  option  to  employ 
existing  data  files  cr  to  generate  his  own.  Standard  output 
procedures  have  been  streamlined  so  that  only  half  the  normal 
number  of  entries  is  required.  This  is  accomplished  by  pre- 
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fo lection  of  damage  accumulation  and  repair-time  parameters. 
Again,  this  pre-selection  may  be  overridden  by  the  user  should  he 
so  desire. 

The  Version  #4  of  NUCDAM  includes  the  unclassified  version 
of  subroutine  RADENV,  with  dummy  values  for  certain  coefficients. 
Prompt  radiation  environments  are  therefore  meaningless  until 
required  changes  are  applied  to  produce  the  classified  version  of 
RADENV.  In  addition,  this  version  of  NUCDAM  does  not  include  the 
additional  nuclear  weapon  effects  incorporated  under  Phase  IIT. 
These  additional  nuclear  weapon  effects  from  underwater  bursts 
included  the  blast  overpressure  along  the  surface  of  the  water 
(psi) ,  the  peak  dose  rate  from  the  base  surge  (Fad/Hr) ,  the  total 
dose  from  the  base  surge  (Rads) ,  and  the  peak  translational 
velocity  (ft/ sec)  which  included  the  effects  of  bottom 
reflection. 
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NUCDAM  VERSION  #5 


Developed  Fran:  PHASE  II T 

Computer:  VAX  11/780 

Language :  FORTRAN 

Current  Distribution:  Naval  Ocean  Systems  Center  (NOSC) 

Boeing  Aerospace  Company 
Titan  Systems ,  Inc. 

Kaman  Sciences  Corporation 
CNO  (OP-654)  (PDP  11/34) 

Notes: 

NUCDAM  Version  #5  (NKISS  NUCDAM  SYSTEM)  was  developed  by 
Kaman  Sciences  Corporation  to  work  in  conjunction  with  the  Battle 
Group  Training  Computer  Support  Facility  (GBTCSD)  as  a  stand 
along  tactical  decision  aid  on  a  VAX  11/780.  The  BGTCSF  offers 
the  opportunity  for  tactical  engagement  raining  through  the 
computerized  wargame  simulation.  The  initial  BGTCSF  simulation 
had  no  nuclear  engagement  capability.  The  NUCDAM  Version  #5  code 
will  give  the  users  of  BGTCSF  the  option  of  having  some  tactical 
nuclear  capability  through  the  stand  alone  simulation  designed  to 
operate  within  the  BGTCSF  framework. 

The  NWISS  NUCDAM  SYSTEM  will  provide  the  player  participat¬ 
ing  in  the  tactical  engagement  training  wargame  the  opportunity 
to  examine  the  possible  effects  of  the  use  of  tactical  nuclear 
weapons  by  either  of  the  forces.  The  NWISS  control  function  will 
also  be  able  to  utilize  the  information  from  the  NWISS  NUCDAM 
SYSTEM  to  make  decisions  as  to  the  effects  of  nuclear  weapons  if 
it  is  decided  that  their  use  is  to  be  employed.  Since  the  NWISS 
NUCDAM  SYSTEM  will  not  have  access  to  the  data  base  of  the 
wargame  simulation,  there  will  be  a  compatible  data  base  designed 
to  allow  stand  along  analysis  in  real  time  during  the  wargame. 
The  data  base  is  designed  by  the  wargame  systems  analyst. 


The  NWISS  NUCDAM  SYSTEM  is  designed  with  four  operating 
functions:  HELP,  BUILD,  TACAID ,  and  NUCDAM.  Each  of  the 
functions  are  described  below. 

The  HELP  function  will  provide  interactive  user  documenta¬ 
tion  on  the  use  of  NUCDAM.  The  HELP  function  is  self -prompting 
and  If -directing.  The  HELP  function  can  be  called  at  any  tine 
during  a  NWISS  NUCDAM  SYSTEM  session.  The  return  of  HELP  to  any 
prompt  will  place  the  user  in  the  HELP  node.  An  END  will 
terminate  the  HELP  session  and  return  to  the  prompt  from  which 
HELP  was  called. 

The  BUILD  function  will  allow  the  game  analyst  to  prepare  a 
data  file  of  the  platforms  (units  involved  in  the  wargane)  and 
the  OATs  (operational  attributes  of  the  platforms)  which  will  be 
used  in  the  wargame .  There  are  two  types  of  entries  in  the  BUILD 
function:  OATs  and  platforms.  The  BUILD  function  will  open  and 
close  the  data  files  as  requested. 

The  TACAID  function  is  a  tactical  decision  aid  to  the  player 
during  a  BGTCSF  wargame.  This  function  allows  the  player  to  see 
the  nuclear  environment  contours  (which  are  in  tabular  form  in 
this  version)  for  environments  of  interest  around  a  potential 
nuclear  burst.  This  will  allow  the  player  to  determine  the 
effects  which  will  be  experienced  by  nearby  friendly,  neutral,  or 
enemy  forces.  The  output  of  the  TACAID  function  will  be  plot 
data  in  tabular  form  which  can  eventually  be  plotted  when  appro¬ 
priate  hardware  is  available. 

The  NUCDAM  function  provides  specific  environment  and  damage 
level  data  for  a  given  platform  and  nuclear  detonation 
combination.  The  information  may  be  of  value  to  the  NWISS 
control  function  for  determining  the  damage  to  a  platform  if  a 
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.nuclear  weapon  is  fired  during  a  game.  It  also  will  be  of  value 
to  a  pleyer  considering  the  use  of  a  nuclear  weapon.  This 
function  can  project  possible  environment  levels  and  damage 
experienced  by  a  specific  enemy,  neutral,  or  friendly  platform. 
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NUCDAM  VERSION  #6 


Developed  From:  PHASE  III 

Computer:  CYBER 

Language :  FORTRAN 

Current  Distribution:  HQ,  DNA  Washington 

McDonnell  Douglas  Corporation 
Kaman  Sciences  Corporation 
McLean  Research  Center 

Notes: 

This  is  the  implementation  of  Version  #5  on  the  CDC  CYBER. 
The  Version  #5  users  guide  will  apply. 

NUCDAM  Version  *5  (NWISS  NUCDAM  SYSTEM)  was  developed  by 
Kaman  Sciences  Corporation  to  work  in  conjunction  with  the  Battle 
Group  Training  Computer  Support  Facility  (BGTCSF)  as  a  stand 
along  tactical  decision  aid  on  a  CYBER  170/730.  The  BGTCSF 
offers  the  opportunity  for  tactical  engagement  raining  through 
the  computerized  wargame  simulation.  The  initial  BGTCSF 
simulation  had  no  nuclear  engagement  capability.  The  NUCDAM 
Version  #5  code  wxll  give  the  users  of  BGTCSF  the  option  of 
having  some  tactical  nuclear  capability  through  the  stand  alone 
simulation  designed  to  operate  within  the  BGTCSF  framework. 

The  NWISS  NUCDAM  SYSTEM  will  provide  the  player  participat¬ 
ing  in  the  tactical  engagement  training  wargame  the  opportunity 
to  examine  the  possible  effects  of  the  use  of  tactical  nuclear 
weapons  by  either  of  the  forces.  Tfca  NWISS  control  function  will 
also  be  able  to  utilize  the  information  from  the  NWISS  NUCDAM 
SYSTEM  to  make  decisions  as  to  the  effects  of  nuclear  weapons  if 
it  is  decided  that  their  use  is  to  be  employed.  Since  the  NWTSS 
NUCDAM  SYSTEM  will  not  have  access  to  the  data  base  of  the 


wargame  simulation,  there  will  be  a  compatible  data  base  designed 
to  allow  stand  along  analysis  in  real  time  during  the  wargame. 
The  data  base  is  designed  by  the  wargame  systems  analyst. 

The  NKISS  NUCDAM  SYSTEM  is  designed  with  four  operating 
functions:  HELP,  BUILD,  TACAID,  and  NUCDAM.  Each  of  the 
functions  are  described  below. 

The  HELP  function  will  provide  interactive  user  documenta¬ 
tion  on  the  use  of  NUCDAM.  The  HELP  function  is  self-prompting 
and  self-directing.  The  HELP  function  can  be  called  at  any  time 
during  a  NWISS  NUCDAM  SYSTEM  session.  The  return  of  HELP  to  any 
prompt  will  place  the  user  in  the  HELP  mode.  An  END  will 
terminate  the  HELP  session  and  return  to  the  prompt  from  which 
HELP  was  called. 

The  BUILD  function  will  allow  the  game  analyst  to  prepare  a 
data  file  of  the  platforms  (units  involved  xn  the  wargame)  and 
the  OATs  (operational  attributes  of  the  platforms)  which  will  be 
used  in  the  wargame.  There  are  two  types  of  entries  in  the  BUILD 
function:  OATs  and  platforms.  The  BUILD  function  will  open  and 
close  the  data  files  as  requested. 

The  TACAID  function  is  a  tactical  decision  aid  to  the  player 
during  a  BGTCSF  wargame.  This  function  allows  the  player  to  see 
the  nuclear  environment  contours  (which  are  in  tabular  form  in 
this  version)  for  environments  of  interest  around  a  potential 
nuclear  burst.  This  will  allow  the  player  to  determine  the 
effects  which  will  be  experienced  by  nearby  friendly,  neutral,  or 
enemy  forces.  The  output  of  the  TACAID  function  will  be  plot 
data  in  tabular  form  which  can  eventually  be  plotted  when  appro¬ 
priate  hardware  is  available. 


48 


The  NUCDAH  function  provides  specific  environment  and  damage 
level  data  for  a  given  platform  and  nuclear  detonation 
combination.  The  information  may  be  of  value  to  the  NWISS 
control  function  for  determining  the  damage  to  a  platform  if  a 
nuclear  weapon  is  fired  daring  a  game.  It  also  will  be  of  value 
to  a  player  considering  the  use  of  a  nuclear  weapon.  This 
function  can  project  possible  environment  levies  and  damage 
experienced  by  a  specific  enemy,  neutral,  or  friendly  platform. 


NUCDAM  VERSION  #7 


Developed  From:  PHASE  III 

Computer:  WICAT  150  WS 

Language:  FORTRAN  77 

Current  Distribution:  Naval  Training  Center,  Orlando,  Florida 

Notes: 

The  NAVTAG  Companion  is  a  self-teaching  study  aid  designed 
to  run  on  a  WICAT  150  as  an  adjunct  to  the  NAVTAG  wargame  system. 
The  Companion  contains  a  nuclear  weapons  primer  and  an  inter¬ 
active  version  of  NUCDAM. 

The  nuclear  weapons  primer  contains  textual  material  and  is 
a  self -prompting  study  guide  to  nuclear  weapons  effects.  The 
primer  is  divided  into  three  sections: 

o  Tutorial  -  each  nuclear  weapon  environment  is 
described. 

o  Operational  Impact  -  each  environment's  impact  on  a 
naval  units  operations  is  discussed. 

o  Tactical  Significance  -  the  significance  of  th  nuclear 
environment  to  the  tactical  siutation  is  discussed. 

The  NUCDAM  portion  of  the  NAVTAG  Companion  is  a  self¬ 
prompting  simulation  which  allows  the  user  to  experiment  with 
nuclear  weapons  and  their  damage  on  tactical  targets.  The  NUCDAM 
portion  is  divided  into  two  sections: 
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o  TT'CAID  -  In  this  module  weapon  parameters  may  be 
specified  and  the  levels  of  nuclear  environment 
examined . 

o  FREE  PLAY  -  In  this  module  the  user  may  specify  a 
tactical  deployment  and  examine  the  operational 
impairment  to  each  unit  from  a  nuclear  attack. 

This  version  of  NUCDAM  is  made  up  of  the  Phase  III  routines 
with  the  bottom  reflection  routine,  BOTREF,  deleted. 
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APPENDIX  A 

VERSION  #2  USERS  GUIDE  (TRS-80) 


TRS-80  NUCDAM 


INTRODUCTION 

Kaman  Sciences  Corporation  (KSC)  has  implemented  the  Phase  II 
NUCDAM  damage  assessment  module  of  the  Naval  Nuclear  Warfare  Simu¬ 
lation  (NNWS)1  on  a  Radio  Shack  TRS-80  Model  I  microcomputer.  The 
implementation  includes  a  simple  interactive  driver  program  to 
allow  the  TRS-80  user  to  specify  the  inputs  to  subroutine  NUCDAM. 
Provision  has  been  made  to  allow  inputs  from  the  keyboard  or  from 
disk.  Outputs  from  NUCDAM  are  sent  to  the  line  printer  by  the 
driver  routine.  The  TRS-80  code  has  been  verified  with  the 
check  cases  used  for  the  PL/I  version. 

In  order  to  implement  NUCDAM  on  a  microcomputer,  the  data 
structure  has  been  reduced.  The  TRS-80  implementation  processes 
one  unit  at  a  time,  with  that  unit  defined  by  up  to  10  Operational 
Attributes  (OAT).  Additional  programming  changes  of  a  minor 

2 

nature  were  also  necessary  to  conform  to  Microsoft  TRS-80  FORTRAN 
restrictions.  TRS-80  NUCDAM  occupies  about  32K  bytes  out  of  a 
maximum  of  48k  bytes  available.  Execution  time  is  quite  fast, 
requiring  only  a  few  seconds  for  a  unit  with  10  OATs.  Minimum 
system  requirements  are  a  TRS-80  Model  I  Microcomputer  with  48K 
RAM  (Random  Access  Memory)  and  one  disk  drive.  For  code  modifi¬ 
cations  using  the  FORTRAN  compiler,  it  is  recommended  that  two 
disk  drives  be  available. 


Griffin,  D. ,  et  al..  Naval  Nuclear  Warfare  Simulation  (NNWS)  Phase  i: 
Damage  Assessment  Module  (U),  Kaman  Sciences  Corporation,  K-80-392(R 
Colorado  Springs,  Colorado.  30  September  1980.  SECRET  RESTRICTED 
DATA/CNWDI . 

2 

TRS-80  FORTRAN  Package,  Microsoft  Consumer  Products,  Bellvue,  Wash¬ 
ington.  19  February  1979.  UNCLASSIFIED. 
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The  delivered  TRS--80  NUCDAH  includes  the  unclassified  version 
of  subroutine  RADENV,  with  dummy  values  for  certain  coefficients. 
Prompt  radiation  environments  are  therefore  meaningless  until  re¬ 
quired  changes,  from  Reference  1,  are  applied  to  produce  the 
classified  version  of  RADENV. 

This  report  documents  the  above  NNWS  NUCDAM  modifications  and 
provides  operational  information  for  the  TRS-80  NUCDAM  implementation. 
It  is  intended  to  be  a  supplement  to  existing  NNWS  NUCDAM  documenta¬ 
tion  (Reference  1).  The  reader  is  assumed  to  be  familiar  with  the 
NNWS  NUCDAM  documentation  and  with  TRS-80  operation. 

DATA  STRUCTURE 

To  reduce  the  size  of  NNWS  NUCDAM  to  be  compatible  with  the 
TRS-80  microcomputer,  it  was  necessary  to  revise  the  data  struc¬ 
ture.  Most  of  the  changes  involve  subroutine  NUCDAM,  primarily 
input/output  and  the  COMMON  blocks.  The  NUCDAM  data  differences 
are  summarized  in  Table  1 . 

The  NUCDAM  calling  sequence  was  altered  to  pass  all  inputs 
and  outputs  through  COMMON  blocks  STVEC  and  VULTAB.  Because  only 
one  unit  is  being  processed  for  each  call  to  subroutine  NUCDAM, 
the  variable  K  indicating  the  unit  number,  is  no  longer  used.  The 
variables  SHIPCAT(K)  and  SCAT  are  also  not  used.  Since  OAT  data 
are  put  directly  into  the  new  VDAT  and  KVDAT  arrays,  the  KROSS 
array  has  been  removed.  The  NNWS  FEGSTAT  array,  containing  avail¬ 
ability  and  estimated  time  to  repair  (ETR),  has  been  renamed  FEGST 
and  dimensioned  for  10  OATs.  The  vulnerability  table  VULDATA  has 
been  reduced  and  split  into  the  arrays  VDAT  and  KVDAT  for  real 
and  byte  variables,  respectively.  Byte  variables 'are  integers 
that  range  in  value  from  -128  to  127  and  can  therefore  be  stored 
in  one  byte.  Only  one  environment  of  concern  is  now  allowed,  i.e.. 


TABLE  1 


NUCDAM  DATA  DIFFERENCES 


NNWS  NUCDAM 

TRS-80  NUCDAM 

COMMENTS 

K 

- 

Not  used. 

SHIPCAT(K) ,SCAT 

- 

Not  used. 

KROSS (K,N) 

Not  used.  OAT  data  put 
directly  into  VDAT  and 
KVDAT  arrays. 

FEGSTAT ( K , N , I ) 

FEGST(N,I) 

OAT  N. 

Dimensioned  Cor  10  OATs. 

VULDATA { KFEG ,  I  ,  J ) 

VDAT ( N  ,  I ) 

OAT  N. 

and  KVDAT ( N , I ) 

Only  1  environment. 

VULDATA(  -  ,1,-) 

KVDAT(-f 1 ) 

2 

- 

Assumed  «  1. 

3 

VDAT  (-,1) 

4 

VDAT  (-r2) 

5 

KVDAT ( —  »  2 ) 

6 

- 

Assumed  «  1 . 

7 

VDAT  (-,3) 

8 

- 

Assumed  *  4.6. 

9 

KVDAT ( —  r  3 ) 

ENVLEV(J) 

ENVLEV(N) 

Changed  to  store  envi¬ 
ronment  for  OAT  N. 

NUNITS,UNITNO, 

XUN  t TUN ,  ZUN  ,  N  KFEG , 

- 

Not  used. 

FEGNAME 
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the  third  dinension  of  VULDATA  has  been  eliminated.  The  relation¬ 
ship  between  VULDATA  items  and  the  corresponding  VDAT  and  KVDAT 
entries  is  indicated  in  the  table.  Note  that  items  2,  6,  and  8 
are  assumed  to  be  constants.  This  is  consistent  with  the  NNWS 
NUCDAM  usage  of  these  variables.  That  is,  items  2  and  6  are 
always  1,  while  item  8  is  always  4.6. 

Since  TRS-80  NUCDAM  allows  only  one  environment  per  OAT,  the 
meaning  of  the  array  ENVLEV  has  been  changed.  For  the  TRS-80  im¬ 
plementation,  ENVLEV  is  dimensioned  to  10  and  used  to  store  the 
environment  for  OAT  N.  As  shown,  the  NNWS  NUCDAM  variables  NUNITS, 
etc.,  are  not  used. 

To  conserve  memory  and  increase  execution  speed,  BYTE  vari¬ 
ables  have  been  used  wherever  possible.  Also,  common  block  /PASS/ 
in  subroutine  BVEL  was  removed,  along  with  references  to  the 
variables  in  /PASS/.  This  was  possible  since  the  original  purpose 
of  these  variables  was  to  aid  in  debugging  and  the  variables  are 
no  longer  used. 

In  examining  subroutine  RADENV,  it  was  noted  that  there  was 
duplication  in  the  environments  coefficients  data  in  arrays  CPN1, 
CGTOT,  etc.  The  coefficients  that  apply  to  weapon  yields  between 
1  and  10  kt  and  between  10  and  40  kt  are  identical.  Thus,  these 
data  tie  re  reduced  from  three  tables  to  two  and  the  environments 
calculations  changed  to  reflect  this. 

PROGRAMMING  CHANGES 

In  addition  to  the  above  changes  to  reduce  the  size  of  NUCDAM, 
all  comment  cards  were  removed  from  the  NNWS  routines  to  keep  the 
size  of  the  source  code  to  a  manageable  level.  Comments  for  these 
subroutines  can,  of  course,  be  found  in  the  NNWS  NUCDAM  listings. 
Because  the  driver  TRSDAM  and  its  subroutines  CLEAR,  OPTHOB  and 
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XREAD  are  not  documented  elsewhere/  comment  cards  were  left  in 
these  listings. 

Several  programming  changes  were  required  because  of  Micro¬ 
soft  FORTRAN  restrictions.  Variable  names  of  more  than  six 
characters  are  not  allowed.  The  PRINT  XX  statements  were  changed 
to  WRITE  (2 /XX)  and  asterisks  (*)  in  FORMAT  statements  replaced 
with  single  quote  marks  (')  around  Hollerith  fields.  Multiple 
statements  per  line,  with  $  characters  as  separators,  have  been 
broken  up  into  multiple  lines.  The  TYPE  portion  of  the  declaration 
statements  has  also  been  removed.  Input  is  now  from  the  keyboard 
(unit  5)  or  disk  (unit  6).  Output  is  directed  to  the  video  (unit 
5)  or  linepr inter  (unit  2). 

Microsoft  FORTRAN  does  not  allow  multiple  entry  points  for 
subroutines,  defined  with  the  ENTRY  statement.  Consequently,  the 
calls  in  NUCDAM  to  various  RADENV  entry  points,  such  as  FN1MEV, 
GTOT,  etc.,  were  changed  to  CALL  RADENV  with  the  flag  IP  in  the 
calling  sequence  set  to  the  appropriate  value.  RDM,  which  was 
not  used  in  the  NNWS  RADENV  subroutine,  has  been  removed  from  the 
calling  sequence. 

VERIFICATION 

In  order  to  ensure  that  the  TRS-80  NUCDAM  implementation  is 
consistent  with  the  NNWS  NUCDAM  code,  an  extensive  matrix  of  cases 
was  crosschecked.  These  cases  included  the  entire  set  of  computer 
runs,  used  to  verify  the  PL/I  version  of  NUCDAM^.  Table  2  shows  a 
sample  run  for  TRS-80  NUCDAM  verification.  Table  3  compares  the 
TRS-80  NUCDAM  results  to  the  NNWS  NUCDAM  for  the  same  OATs  and 


^Verification  of  PL/I  Version  of  NUCDAM,  Kaman  Sciences  Corporation, 
K-80-24U(M),  Colorado  Springs,  Colorado  Springs,  Colorado. 

4  March  1980.  UNCLASSIFIED. 
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TABLE  2 


SAMPLE  VERIFICATION  RUN 


ICICMT  OF  TARGETCFT)  0.  COLLMPSE  DEPTHCFT)  2000. 

HULL  RADIUSCFT)  16.  HULL  DEPTHCFT)  30. 


OftT 

OAT 

lilt. 

EHOIR 

MOSEL  LWIF 

110 

ISO 

DAMAGE 
ACC  HOD 

A 

IMAX 

AVAIL 

ETR 

1 

Hill 

4  OVPRES 

S.08C-G1 

S.00E400 

1 

.AC 

90 

100. 

0. 

2 

coni 

5  EMPFLD 

3.70E433 

3.40E+04 

1 

.40 

50 

100. 

0. 

3 

MD2 

C  MlflEV 

E.00C+09 

5.40E+10 

1 

2.4E 

85 

100. 

0. 

A 

COM2 

7  GTOT 

1.66E+02 

1.50E+03 

1 

.90 

SS 

100. 

0. 

5 

COM3 

9  GDOT 

5.00E+07 

5.00E408 

i 

1.20 

80 

100. 

0. 

e 

COM4 

9  XRAY 

2  73E+00 

2.50E  >01 

1 

.40 

60 

100. 

8. 

7 

HB3 

18  GP 

1.00E403 

1.O0E404 

« 

A. 

.40 

75 

100. 

0. 

e 

C0M5 

11  TISSUE 

1 . 40E+07 

1.50E407 

1 

2.4U 

6S 

100. 

3. 

a 

PERI 

12  THERML 

1.00E+02 

1.O0E+03 

1 

.90 

70 

100. 

0. 

YIELBiKT) 

130. 

HOBfFT) 

2000. 

GRCFT) 

7500. 

OAT 

ENVIRONMENT 

OAT 

VRA. 

ENUIR 

LEUEL 

AVAIL 

ETR 

i 

HDl 

OUPRES 

7. 33E+00 

0.  999939. 

2 

coni 

EMPFl.C 

6-05E+03 

94. 

27. 

3 

HD2 

N1HEV 

6. 40E+09 

89. 

91. 

A 

COM2 

GTOT 

5.32E+01 

36. 

.*0. 

5 

COM3 

GDOT 

1 .38E+07 

9G. 

13. 

A 

COM4 

XRAY 

8.00E+00 

100. 

0. 

7 

WD3 

GP 

2.17E+00 

99. 

1. 

8 

COTS 

TISSUE 

2.36E+02 

100. 

0. 

9 

PERI 

THERML 

5.40E401 

9 A. 

17. 
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other  inputs;  only  ground  range  is  varied.  The  comparison  is 
obviously  favorable.  Similar  results  were  obtained  for  the  other 
test  cases. 

OPERATIONAL  INFORMATION 
Execut ion 

The  TRS-80  NUCDAM  code,  including  the  driver  routine,  is  a 
command  file  on  the  TRS-80  disk  labeled  "EXECUTION".  The  TRS-80 
file  name  of  the  executable  code  is  NUCDAM/CHD.  To  execute  the 
code,  insert  the  EXECUTION  disk  into  drive  0  and  press  the  reset 
button.  At  DOS  READY,  key  in  NUCDAM,  followed  by  <enter>  and  the 
program  will  begin  execution.  Inputs  are  entered  by  following 
the  prompts  displayed  on  the  video.  Output  is  to  the  line  printer. 
Damage  calculations  are  performed  for  one  unit  at  a  time,  with  up 
to  10  OATs.  The  user  is  given  the  option  of  repeating  the  calcu¬ 
lation  for  other  units. 

Input/Output 

Table  4  describes  the  input  required  for  TRS-80  NUCDAM.  The 
first  input  is  whether  or  not  analysis  is  to  be  on  an  existing 
unit,  i.e.,  one  that  is  already  stored  on  disk.  If  answered  N 
for  no,  the  user  is  prompted  to  enter  values  for  the  target 
parameters  shown  in  Table  4. 

Numeric  values  should  be  entered  as  either  integer  or  real 
variables,  with  the  appropriate  decimal  point,  and  may  be  in  the 
FORTRAN  scientific  notation  E-format,  if  desired.  Values  input 
are  followed  by  <enter>.  For  up  to  10  OATs,  inputs  as  indicated 
are  entered.  Each  OAT  is  identified  by  a  user-input  name.  This 
name  is  an  alphanumeric  label  used  only  in  the  printout  and  is 
5  characters  in  length.  If  fewer  than  8  characters  ate  used,  it 
is  recommended  that  trailing  blanks  be  added.  The  three  OAT 
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TABLE  4 


INPUTS 


EXISTING  UNIT  (Y/N)  -  Y  if  unit  is  stored  on  disk 

N  if  input  is  from  keyboard 

♦TARGET  HEIGHT  (FT)  -  use  <0  if  underwater 

•HULL  RADIUS  (FT) 

♦COLLAPSE  DEPTH  (FT) 

♦BOLL  DEPTH  (FT) 

FOR  EACH  OAT: 

♦OAT  NAME  -  used  as  identifier 

♦ENVIRONMENT  MODEL 

(DAMAGE  model  -  assumed  to  be  1 ) 

*110  -  Environment  level  for  10%  impairment 

*190  -  Environment  level  for  90%  impairment 

♦DAMAGE  ACCUMULATION  MODEL 

(ETR  MODEL  INDEX  -  assumed  to  be  1 ) 

♦A  -  ETR  model  linear  multiplier 

(B  -  ETR  model  exponential  coefficient,  assumed  to  be  4.6) 

•IMAX  -  Impairment  level  at  which  ETR  is  infinite 

♦AVAILABILITY  -  initialized  by  program  to  100%  when  OAT 

defined 

♦EXPECTED  TIME  TO  REPAIR  (MIN)  -  initialized  to  0  when  OAT 

defined 

YIELD  (KT) 

HEIGHT  OP  BURST  (FT)  -  use  <0  if  underwater 

If  ”999."  entered  for  Height  of  Burst, 
optimum  height  of  burst  selected  for  input 
psi  level 

GROUND  RANGE  (FT) 

TIME  (MIN) 

FILESPEC  -  er  to  24  character  TRS-80  file  specification  in 
format  name/extension. password :drive  number 


♦Saved  on  disk 


items  in  parenthesis  are  not  explicitly  entered,  but  are  assumed 
to  be  the  values  shown  in  the  table.  These  values  are  consistent 
with  the  HNWS  NUCDAH  vulnerability  tables.  That  is,  the  damage 
model  and  ETR  model  index  in  every  case  are  both  1*  and  the  ETR 
model  exponential  coefficient  b  is  always  4.6  in  NNWS  HOC DAK. 

The  OAT  availability  and  expected  time  to  repair  (ETR)  also  are 
not  explicitly  input,  but  are  initialised  by  the  program  to  1001 
availability  and  zero  ETR  at  the  time  the  OAT  is  defined.  For 
further  definition  of  these  OAT  parameters,  sec  the  NNtiS  NUCDAH 
documentation  in  Reference  1. 

Following  the  OAT  data  input,  the  user  is  asked  if  the  unit 
should  be  saved  on  disk.  If  answered  Y  for  yes,  the  user  inputs 
the  unit  filespec  in  the  standard  TRS-80  format  of  name  (/extension) 
( .password) (:drive  number),  where  the  bracketed  portions  are  op¬ 
tional.  The  stored  inputs  in  Table  4  are  then  written  to  disk. 

The  disk  files  created  in  this  manner  may  be  loaded  by  reference 
to  the  filename  in  subsequent  NUCDAH  runs. 

The  nuclear  burst  parameters  of  yield,  height  of  burst  and 
ground  range  are  next  entered.  If  the  height  of  burst  is  entered 
as  *999.",  the  program  will  compute  the  height  of  burst  required 
to  optimize  the  blast  radius  to  a  given  overpressure  level,  from 
1  to  100  psi.  The  user  is  then  given  the  option  of  using  the  com¬ 
puted  burst  height  or  entering  another  value.  The  input  variable 
TIHE  is  the  current  NNWS  simulation  time,  used  to  update  the  ex¬ 
pected  time  to  repair  for  each  OAT. 

Output  data  is  printed  on  the  line  printer.  A  sample  out¬ 
put  is  shown  in  Table  5.  The  first  item  is  a  table  of  labeled 
input  data.  This  table  should  be  carefully  examined  to  ensure 
that  the  desired  inputs  have  been  correctly  entered.  As  NUCDAH 
progresses,  the  various  subroutines  check  to  see  if  the  target 
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TABLE  S 


SAMPLE  OUTPUT 


JCttHT  OF  TARGETCFT)  1000.  COLLAPSE  DEPTH* FT)  2000. 

..HBLL*WDIU5(FT)  16.  HULL  DEPTH* FT)  30. 

OAT  ENVIR  DAMAGE 


OAT 

NAME 

MODEL 

ENVIR 

110 

190 

ACC  MOD 

A 

IMAX 

AVAIL 

ETR 

1 

WD1 

4 

OVPRES 

S.00E-01 

S.00E+00 

1 

.40 

90 

100. 

0. 

2 

corn 

5 

EMPFLD 

3.70E+03 

3.40E+04 

1 

.40 

50 

100. 

0. 

3 

UDZ 

6 

N1MCV 

6.00C409 

5.40E+10 

1 

2.40 

65 

100. 

e. 

4 

COM2 

7 

GTOT 

1 . 60E+02 

1.50E+03 

1 

.90 

55 

160. 

0. 

YIELD*  KT )  100. 

HOB(FT)  2000. 

GR(FT)  6000. 

+++++  S/R  OOF  RES  IS  NOT  APPLICABLE  FOR  HOB  «  2000. 00  AND  HTARG  *  1000. 


01  T  ENVIRONMENT 

OAT  NAME  ENVIR  LEVEL  AVAIL  ETP 


1 

WD1 

OVPRES 

0.00E+O0 

100. 

0 

2 

COM1 

EMPFLD 

1 . 72E+04 

54. 

173 

3  . 

MD2 

N1MEV 

8.75E+10 

0. 

999999. 

'1*  V 

COM2 

GTOT 

2.98E+02 

82. 

71 

A-ll 


and  burst  altitudes  (or  depths)  are  appropriate.  In  the  example, 
a  warning  is  printed  that  subroutine  OVPRES  is  not  applicable 
for  the  non-zero  target  altitude.  The  calculated  environment 
levels,  availability  in  percent  and  expected  time  to  repair  (ETR) 
in  minutes  are  then  printed  for  each  OAT. 

At  this  point,  the  unit  data  may  be  saved  on  disk,  as  before. 
The  saved  availability  and  ETR  for  each  OAT  are  the  calculated 
values,  such  as  those  at  the  bottom  of  the  sample  output  in 
Table  5. 

Code  Modifications 


In  the  event  that  code  modifications  to  TRS-80  NUCDAM 
are  necessary,  the  FORTRAN  compiler  must  be  used  together  with 
the  SOURCE  disk.  Table  6  illustrates  one  way  to  modify  the 
NUCDAM  source  code.  For  further  clarification  and  explanation 
of  other  user  options,  please  see  the  Microsoft  FORTRAN  manual. 

The  FORTRAN  and  SOURCE  disks  are  placed  into  drives  0  and 
1,  respectively,  and  the  system  reset.  At  the  DOS  READY  prompt, 
the  user  enters  EDIT  followed  by  <enter>  to  load  the  FORTRAN 
text  editor.  The  editor  will  request  a  FILE:,  which  should  be 
answered  NUCDAM/F0R:1  <enter>.  This  will  cause  the  NUCDAM 
source  code  to  be  loaded  from  disk  1.  This  file  can  be  modified 
as  desired.  Because  of  the  wide  variety  of  possibilities, 
the  editing  procedure  is  not  described  here.  It  is  suggested 
that  the  EDIT-80  portion  of  the  FORTRAN  manual  be  consulted. 

When  code  modifications  are  complete,  the  edited  file  can  be 
written  to  the  SOURCE  disk  (or  a  formatted  scratch  disk  in  drive 
1)  by  keying  in  E  NUCDAMB/FOR: 1  followed  by  <enter>.  Note  that 
the  revised  file  does  not  have  the  same  name  as  the  initial  source 
file.  The  same  name  NUCDAM/FOR  is  not  permitted  by  the  editor; 
it  is  necessary  to  create  a  backup  file  NUCDAMB/FOR. 
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TABLE  6 


CODE  MODIFICATIONS 


(1)  Insert  FORTRAN  disk  into  drive  0  and  press  reset 

(2)  Insert  SOURCE  disk  into  drive  1 

(3)  EDIT  <enter>  -  Loads  text  editor 

(4)  FILE:  NUCDAM/FOR: 1  <enter>  -  Loads  NUCDAM  text 

(5)  Make  changes  as  desired 

(6)  Insert  SCRATCH  disk  into  drive  1  if  desired 

(7)  *£  NUCDAMB/FOR : 1  <enter>  -  Writes  edited  file  to  drive  1 

(8)  F8fl  =NUCDAMB  <enter>  -  performs  syntax  check 

(9)  Repeat  steps  (2)  to  (8)  as  necessary 

(10)  KILL  NUCDAM/FOR  if  desired  -  lose  backup  file  of  NUCDAM 

(11)  RENAME  NUCDAMB/FOR  TO  NUCDAM/FOR  <enter> 

NOTE:  User  inputs  are  underlined 


If  the  file  is  successfully  written,  the  editor  exits  to 
DOS  READY.  At  this  point,  a  syntax  check  may  be  made  by 
entering  F80  *=NUCDAMB  <enter>.  The  FORTRAN  compiler  F80  will 
process  the  revised  source  code  and  syntax  errors  will  be  dis- 
played  on  the  video.  If  errors  exist,  the  source  code  must 
again  be  edited  as  outlined  above.  It  should  be  noted  that  the 
exit  from  the  editor  must  be  made  with  an  unassigned  file  name, 
i.e.,  NUCDAM/FOR  may  not  be  used  in  the  second  pass.  When  syn¬ 
tax  errors  have  been  eliminated,  the  original  NUCDAM/FOR  file 
may  be  killed  if  desired.  This  will,  of  course  result  in  the 
loss  of  the  NUCDAM  backup  file,  which  is  not  necessary  if  a 
scratch  disk  has  been  used.  The  NUCDAMB/POR  file  can  then  be 
renamed  NUCDAM/FOR. 

Compilation 

A  representative  procedure  for  compilation  is  shown  in 
Table  7.  After  loading  the  appropriate  disks  as  shown,  and 
resetting  the  system,  the  user  can  key  in  T80  <enter>  to  load 
the  FORTRAN  compiler,  which  will  display  an  asterisk  prompt.  The 
command  NUCDAM :1*NUCDAM:1  <enter>  will  create  the  relocatable  object 
file  NUCDAM/REL  on  drive  1.  The  <break>  key  may  be  used  to  exit 
the  compiler.  An  alternate  command  , NUCDAM :1 -NUCDAM :1-N  <enter> 
will  create  a  listing  file  NUCDAM/LST  on  drive  1  that  can  be 
listed  by  the  DOS  PRINT  or  LIST  commands.  Unfortunately,  the  NUC¬ 
DAM  code  is  too  large  to  permit  both  the  relocatable  object  code 
and  listing  files  to  be  generated  simultaneously  on  one  disk. 

When  the  object  code  is  stored  on  disk,  the  linking  loader 
may  be  loaded  by  L80  <enter>.  The  input  NUCDAM, FORLIB  <enter> 
will  cause  the  loader  to  load  the  NUCDAM  code  and  search  the 
FORTRAN  library  FORLIB  for  necessary  subroutines.  The  EXECUTION 
disk  or  a  formatted  scratch  disk  should  be  inserted  into  drive  1. 
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TABLE  7 


COMPILATION 

(1)  Insert  FORTRAN  disk  into  drive  0  and  press  reset 

(2)  Insert  SOURCE  or  scratch  disk  into  drive  1 

(3)  F8g  <enter>  -  Loads  the  compiler 

(4)  *NUCDAM; 1=NUCDAM: 1  <enter>  -  Creates  object  file  on 

drive  1 

(5)  Use  <break>  to  exit  compiler 


NOTE:  User  inputs  are  underlined 
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The  command  NUCDAM:1-N-E  to  the  linking  loader  will  then  create 
an  execution  file  NUCDAM/CMD  on  drive  1.  This  file  will  replace 
the  existing  NUCDAM/CMD  file  if  the  EXECUTION  disk  has  been  used. 
Execution  then  begins  with  NUCDAM  <enter>  in  response  to  DOS  READY. 
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A.  Program  Overview 


NUCDAM  is  the  Nuclear  Damage  Assessment . Module  of  the  Navy 
Nuclear  Warfare  Simulation  (NNWS) ,  which  was  developed  under  CNO 
(OP-654)  sponsorship.  The  Phase  2  version  of  NUCDAM  has  been 
implemented  on  the  Wang  2200  T/VP  computers.  NUCDAM  models 
damage  to  submarines,  surface  ships  and  land  targets  occuring 
during  a  tactical  nuclear  engagement.  Targets  are  represented  by 
a  group  of  operational  attributes  (OATs)  describing  the 
vulnerability  of  certain  shipboard  systems  to  the  appropriate 
nuclear  environments.  Representative  OATs  have  been  pre-de fined 
for  several  generic  target  types,  and  the  user  may  define 
specific  targets  as  desired. 

The  operation  of  the  Wang  2200T/VP  version  of  NUCDAM  is 
illustrated  here  with  step-by-step  instructions  showing  the  flow 
of  NUCDAM  input  and  output,  with  a  specific  example  included. 

More  detailed  definition  of  the  inputs  and  outputs  is  then  given. 


B-l 


u 

o 

0 

<  a 
H  <  Z 
*3  O  D 
U  »4  PC 


Q  < 
U  £ 
D  < 

z  0 


(0 

w 

o  o 

£  Z 
pa  m 

H  M 
O  M 

co  »a 
< 

Z  M 
<  H 


PC 

CO  H 

s  s 

O  K 
fc.  H 
E-*  CO 

S  S 

***  PC 
H  W 
pa  co 

O  M 
PC  D 
<  PC 

H  o 
pa  pa 

►J  => 
to  »a 
#c  id 
*4 


CO 

g 

PC  M 

pa  pa 

H  M 

PC  X 
os  a. 

8  S 

pa  pa 
z>  D 
*a  »a 
pa  pa 


pa  pc 

z  « 

H  CO 
PC  H 

s  s 

pa  o 
» 

co  pa 
o 

pa  z 

3  25 

pa  o 


co 

D  w 
o  z 

PC  W  M 

pa  pa  z 

H  H  < 
OS  X  £ 
os  a.  pa 
<  Z  r? 
o  2  co 


pa  pa  pa 
o  o  o 
z  z  z 

el  p!  ci 
o  o  o 


«c  — 

a  - 


n  n  in  w  Is-  0 


n 

o 

c 

o 

4J 

•o 

o 

(0 

O 

c 

•• 

■  f  l 

H 

H 

CO 

o* 

4J 

a 

K 

c 

o 

a> 

•H 

3 

4J 

> 

h 

E 

•ri 

o 

*» 

a 

0) 

Pi 

H 

0) 

Pi 

H 

•o 

H 

c 

O' 

o 

M 

z  o 

o> 

X 

O  ^ 

x 

co 

O' 

m  a 

*i 

-H 

V 

c 

•0 

X 

•H 

O  •C 

c 

4J 

4J 

z>  «. 

0) 

10 

0  0 

X 

4J 

h 

E-*  «-• 

4J 

3 

V 

CO 

co 

a 

a 

z  o 

-rA 

U-i 

c 

o 

M  H 

•o 

O 

-cH 

1 

O 

1 

H 

0) 

01 

o 

Pi 

O 

p« 

ja 

10 

X 

pa 

a 

0)* 

o 

*— i 

0) 

a 

H 

0 

01 

r— 1 

x: 

e. 

r-l 

< 

ja 

•H 

-U 

c 

•H 

H 

» 

rH 

•o 

r— i 

•o 

p-« 

c 

c 

c 

c 

c 

•H 

V 

<0 

0) 

0) 

CO 

o? 

0) 

0) 

Pi 

•o 

Pi 

Pi 

•o 

CO 

u 

0> 

O' 

U 

O 

01 

z 

10 

Pi 

c 

10 

CO 

Pi 

o 

<0 

•H 

« 

H 

0) 

0) 

0) 

» 

0) 

H 

£ 

r-A 

c 

X 

£ 

r-l 

0 

O 

H 

O 

o 

(9)  -EXISTING  USER  DEFINED 

(10)  NEW  USER  DEFINED 
SELECTION 


I 


! 

y 


.1. 
v*  *. 

fe 


it 

I. 


1 


I 

wJkt 

\ 


\ 

•  .*• 
L_ 

S'". 

.V*. 


f* 

D 

04 

z 

H 


w 

X 

0. 


X 

w 


h 

to 

M 


>« 

< 

0. 

to 


X 

H-i 

1 

US 

O' 

o 

-4-1 

•H 

3 

K 

X 

O 

1 

a 

Vl 

c 

u 

H 

«M 

os 

3 

•0 

• 

0 

x 

H 

O 

Oi 

O 

a 

0) 

-r< 

X 

•H 

•o 

V4 

a 

X 

0) 

O' 

X 

>- 

O 

4-1 

• — 1 

a 

«0 

X 

Z 

V 

Vl 

-H 

c 

X 

o 

4-1 

0) 

X 

X 

a 

M 

V 

o 

us 

us 

> 

•H 

m 

3 

« 

X 

V4 

X 

u 

0) 

O 

o 

US 

D 

« 

3 

V 

0) 

•c 

X 

o: 

X 

r— 1 

X 

US 

U 

0) 

u 

t- 

x 

K 

4J 

o 

0) 

X 

CO 

to 

co 

> 

o 

c 

-4-1 

E-* 

r—i 

2 

«W 

X 

0) 

Vl 

< 

3 

H 

M 

to 

03 

o 

O' 

o 

O 

o 

0) 

i 

O' 

• 

1 

• 

04 

c 

c 

c 

«s 

H 

■44 

e 

a 

■H 

X 

•4-1 

1 

X 

0) 

Vi 

>4 

*4 

us 

to 

R 

O 

X 

US 

f-l 

«s 

D 

■rl 

H 

« 

V 

0) 

a 

• 

•H 

» 

H 

X 

CS| 

Ov 

? 

X 

Ou 

Vi 

X 

X 

3 

-rt 

OS 

•H 

US 

a 

c 

Sj 

a 

X 

•4-1 

* 

X 

0) 

o 

OS 

e 

US 

4— 1 

3 

us 

X 

-H 

OS 

•H 

Vi 

• 

a 

3 

CO 

X 

3 

c 

to 

®l 

r* 

c 

0 

u 

o 

os 

•W 

-H 

0 

0) 

O 

X 

04 

X 

X 

f— 1 

X 

o 

•o 

as 

c 

•H 

OS 

X 

•c 

OS 

X 

• 

<0 

X 

a 

US 

OS 

OS 

X 

CO 

O' 

a 

•H 

X 

B 

•H 

• 

US 

B 

«M 

3 

«s 

n 

V4 

o 

0> 

to 

to 

CO 

M 

e. 

10 

c 

o 

X 

04 

w 

CO 


r> 


B-3 


H 

t> 

p. 

v  z 


<3 

V, 


B 

Z  — 
M  E-« 
K  b 


£  -  i 


10  X 
D  H 
(0  P. 
B 

X  O 

h*  o 
B  Z 

x  £ 

g  5 

B 

O)  P. 

H  o 


o 

e 

o 

o 

in 

00 

1 

n 

r* 

1 

V 

c 

0 

■H 

P 

H 

c 

0 

• 

e 

E 

X 

0 

3 

H 

0 

0 

« 

0 

P 

P 

C 

O 

*o 

H 

c 

B 

0 

->-• 

0 

« 

> — . 

•rl 

0 

—» 

H 

X 

X 

H 

B 

H 

P 

p 

b 

P. 

0 

■ 

B 

O' 

o 

CO 

O 

n 

p 

X 

D 

0 

H 

n 

B 

P 

a 

P. 

Q 

(0 

-rl 

B 

X 

P. 

<M 

X 

a 

2 

< 

M 

0 

•4 

«>■» 

►3 

£ 

►J 

O 

o 

E5 

O 

X 

X 

o.  *o 

•  • 

P  P 

•  c 
m 

c  o. 

9  9 

£  u 
*> 

9 

Z  £ 


h  >«  m  h  s  » 


0 

3 

c 

C 

o 

0 

•*4 

E 

p 

•rl 

H 

•c 

X 

•o 

o 

0 

0 

N 

n 

0 

h 

3 

B 

B 

p 

o 

C 

r-t 

w 

0 

%A 

-rl 

o 

• 

• 

rf 

m 

0 

P 

J  01 

n 

,'r 

N  • 

m 

>* 

a 

0 

Z 

3 

C 

c 

o 

M 

0 

o 

E 

z 

o 

H 

p 

B- 

X 

0 

o 

h 

3 

0 

C 

p 

0 

•rl 

0 

3 

z 

P 

0 

B 

c 

X 

0 

O 

>« 

o 

0 

£ 

O 

o 

u 

o 

r*l 

X 

o 

o 

H 

Z 

o 

p 

p 

0 

o 

»3 

M 

H 

u 

h 

Z 

—  B 

H 

X 

9 

0 

X  O 

X 

o 

0 

4—*. 

0 

X  o 

B 

3 

z 

3 

0 

X  z 

D 

to 

0 

o 

Z 

M 

0 

>« 

0 

•w 

P 

X  CD  H  E> 

O  Z  O 

B  O 

XUS  X 

2  5  g 

z  «  o 

-CM  < 

h  H  >  o  O  £ 

x  x  z  m  o»  a 

a  o  b  m  w  a 


HO  O  £ 

H  «fl  H  -rl 

K  H  h  H  h 

O  *  X  «  JJ 

B  O  ** 
>*  *  « 

X  <  — ’  B  — ’ 

X  H  X 

2  x  o 

X  M  Q  x 


I  c 

c  • 

-rl  X 

P 

* 


O  -rl 
*-«  ) 

C  Vi 

o  0 

-r+  0 

P  3 
O 

0  O 
«-i  X 

O  P 
0 

*1 

«m  3 

_  ft 


« 

•  c 

X  o 

p  I 
>• 
P  X 
3  I 

a  c 
c  c 
M  O 

o  « 

p  p 
0 

■o  *o 
« 

X  P 
-0  0 
«  tr 
p 

«  e 

n  p 


0 

-rl 

X 

1 

* 

p 

0 

>4 

0 

0 

c 

0 

0 

c 

0 

a 

p 

o 

0 

o 

3 

1 

n 

X 

>S 

u 

u 

-rl 

£ 

0 

o 

M 

1 

p 

0 

0 

p 

c 

X 

0 

0 

o 

p 

p 

0 

f-t 

Vi 

Vi 

0 

0 

0 

0 

3 

c 

0 

0 

IT 

o 

U. 

H 

0 

•rl 

a 

o 

Vi 

P 

0 

VA 


Hi 


H 


2 

t 

to 


FT  i 


Z 

O 

H 

o 

z> 

t* 

E* 

in 

z 

4-4 


P. 

W 

in 


c 

o 

a 

0 

* 


m 

« 

£ 

n 


4» 

3 

a 

c 


>•  9 


CM 

E* 

0) 

H 


3 

C 


£ 

*> 


O 

4J 


E«  Z 

4J 

c 
o 
o 


c 


3 

C 

■ri  <■». 

V  CD 


o  a 
u  t 


a 

© 

** 

m 


z 

cn 

o 

4J 

z 

i 

*>*. 

« 

£ 

c 

>t 

*» 

c 

z 

u 

a 

0 

o 

« 

X 

•v 

-p-i 

>* 

£ 

to 

£ 

— — 

4-1 

in 

r 

e 

O 

E 

z 

H 

€ 

£ 

to 

tr 

« 

»-« 

o 

> 

V: 

w 

h 

b. 

0 

O 

Sh 

in 

>• 

CP 

o 

« 

V-c 

£ 

< 

O 

X 

El 

C 

o 

%-« 

M 

5 

>• 

-.4 

z 

-«-4 

a 

B 

o 

H 

« 

w 

•w 

> 

x 

o 

< 

4-4 

o 

VC. 

to 

fc. 

x 

o. 

c  © 

v  > 

6  « 

i4  a 

u 

«  c 

*i  x 

V  ** 
£  K  « 

41  -P  •C 

r 

m  «  -a 
*  3  3 

«  r  s> 

-i  «j  e 
u  w  -w 


o 

o  o 
«*»  o 

H  CM 


CM 


o 

o 

o 


o  >* 


E* 

K 


O 
*4 
H  M 
H  H 

JH  X 


c 

41 

• 

£ 

£ 

O' 

41 

■H 

• 

tr> 

£ 

CP 

tc 

o\ 

a 

O 

4-* 

4J 

1 

X 

©4 

4-4 

04 

h 

£ 

E* 

04 

a 

c 

* 

a 

z 

« 

h 

o 

"V. 

3 

fr> 

3 

>* 

b. 

£ 

o 

c 

«-» 

E* 

M 

u 

3 

E* 

C 

t4 

44 

4> 

to 

U 

n 

• 

s 

£ 

> 

E* 

< 

*4 

£> 

£ 

» 

tu 

E« 

A 

o- 

*3 

'■» - 

O. 

H 

•H 

H 

H 

k 

© 

4-4 

a 

O 

-r4 

O 

£ 

X 

o 

O 

tu 

X 

< 

fc« 

z 

X 

-rt 

•— • 

o 

t«  El 

(M  fe 


£  K 
•  O 

H  Z  - 
3  <  Z 
£  X  w 
T. 


O  X 

K  H 

O  E* 


£ 

31 


JC 

1 

3 

© 

K 

® 

O 

• 

*» 

-r-i 

m 

V* 

K 

• 

« 

*c 

© 

c 

Vi 

41 

3 

V 

o 

C 

C 

« 

c 

4J 

r-l 

•H 

Vi 

o 

z 

41 

O 

a 

© 

K 

c 

K 

« 

> 

c 

C 

0 

© 

© 

K 

© 

5 

u 

© 

C 

V, 

£ 

o 

C 

V; 

41 

4J 

1 

© 

Vi 

o 

© 

0 

£ 

© 

•H 

c 

i4 

c 

£ 

£ 

* 

41 

3 

m 

3 

I 

W 

U 

© 

CT 

« 

4t-i 

c 

c 

© 

4  * 

»-l 

0 

#— 4 

<r. 

u 

X 

6 

OD 


B-5 


:«• _ _ 


THREAT  DATA  CORRECT  (Y/N) 
(N  repeats  Step  8) 


F« 

'jf  2 

z 

H 


‘  *  * 

X 

o 

— * 

> 

>• 

\- 

< 

m~  j 

*3 

o 

X 

X 

X 

a 

*- 

H 

H 

a 

>  — 

a 

X 

o 

t* 

*• 

X 

.  * 

*  *, 

F*  « 

. » 

D 

►  * 

X  Z 

F*  H 

D  X 

k,- 


z 

o 

M 

F« 

o 

a 

X 

to 

z 

M 


x 

w 

F* 

to 


O  0. 


o  © 

x 


F« 

u* 


X  F* 
H  Im 
0. 

W 

O  X 
F 
U  P. 
to  H 
P>  O 
< 

.3  *3 
*3  *3 

o  a 
o  x 


c 

— 

o 

in 

> 

"m 

•H 

o 

*> 

X 

a 

a 

F 

X 

a 

4-1 

~— 

a 

9 

a 

F* 

%4 

« 

c 

X 

F« 

o 

X 

•H 

O 

X 

X 

»— • 

0 

H 

< 

c 

H 

o 

F* 

X 

e 

■H 

a 

« 

4-1 

X 

H 

E 

a 

O 

o 

>s 

a 

< 

41 

4J 

a 

a 

F« 

X 

o 

9 

H 

a 

X 

e 

X 

a 

>4 

o 

•3 

*-4 

♦» 

a 

l-l 

•3 

• 

9 

•H 

a 

X 

a 

X 

0 

D 

X 

X 

x 

£ 


I 


oooooooo 


O  ©  ©  © 
o  o  o  o 


o  o  o 
o  o  o 


OV 


> 

z 

w 


X  *3 
M  H 

>  c 
z  o 
w  £ 


w 

£  5 

c  z 


F> 

< 

o 


i.oxxooxxo 

oima>mcou>r'Wr' 


CM 


CM 


to  a 

w  *3  > 

«  X  H  H  F*  >* 

0.  O.  £  O  O 

>  £  *-«  F*  O 

O  W  Z  O  O  X 


r'- 

£ 


H  *3 

§  § 

X  U 

x  m  x 

O  F*  F* 


lAWt'OAOHCM 


o 

Z 


rH 

£ 

CM 

CM 

£ 

n 

£ 

£ 

n 

m 

£ 

rd 

X 

O 

O 

O 

O 

O 

O 

O 

u 

V 

z 

U 

U 

O 

z 

O 

X 

CM 

n 

mt 

m 

u> 

r~ 

eo 

o> 

X 

F 

H 

T> 

C 

0 


5 

< 


c 

E 

9 

H 

o 

u 

% 

41 


X 

o 


o 

ar 

o 

to 

a 

rH 

r- 

X 

X 

o 

o 

•-* 

o 

o 

o 

O 

o 

o 

+ 

+ 

+ 

+ 

+ 

+ 

+ 

+ 

♦ 

0 

M 

U 

H 

H 

§3 

w 

H 

H 

u 

X 

o 

O 

O 

O 

O 

o 

O 

O 

o 

•9 

o 

«• 

X 

o 

X 

o 

X 

o 

x 

M 

X 

H 

X 

CM 

H 

H 

rH 

X 

«4 

•-i 

x 

Ox 

CM 

O 

X 

X 

o 

o 

O 

o 

o 

o 

O 

o 

o 

i 

■o 

i 

♦ 

+ 

+ 

♦ 

+ 

+ 

♦ 

+ 

0 

w 

M 

H 

H 

m 

N 

H 

H 

u 

0 

o 

o 

o 

o 

o 

a 

o 

o 

o 

4» 

o 

r- 

o 

X 

o 

p* 

o 

MT 

o 

a 

0 

0 

a 

0 

0 

0 

0 

0 

0 

c 

X 

n 

io 

rH 

X 

CM 

rH 

rH 

rH 

•H 

4J 

u 


0 

* 

> 

%4 


o 

X 


0 

X 

4) 

o 

c 


9 

o 


B-6 


(If  Video  (V)  selected  PRESS  RETURN  TO  CONTINUE 


INSTRUCTION  DISPLAY  EXAMPLE  INPUT 


w 

o 

X 

M 

t* 

►4 

X 

M 

o 

X 

o 

o 

O 

o 

> 

m 

o 

O 

X 

rl 

o 

o 

o 

fk 

m 

H 

X 

x 

z> 

H 

t* 

H 

X 

K 

«•*. 

H 

H 

w 

H 

X 

X 

•4 

X 

X 

u 

D 

fr. 

to 

o 

p 

•4 

*»•» 

CO 

X  1 

in 

fa 

A 

H 

H 

•4 

H 

O 

X 

X 

> 

>• 

X 

19 

X 

§ 

•o 

0 

X 

4> 

0 

1 

M 

O 

E 

«-» 

> 

M 

kw 

0 

L 

0 

0 

X 

0 

o 

H 

O 

o 

0 

0 

w 

0 

-C 

• 

41 

« 

|4 

0 

4» 

0 

A 

a 

0 

4» 

A 

• 

a 

0 

•c 

H 

a 

> 

•H 

c 

H 

r-l 

o 

« 

■»— 

E 

Li 

0 

H 

E 

-r4 

h 

4J 

0 

a 

•H 

►  > 

0 

o 

Li 

c 

r 

X 

& 

« 

•D 

0 

tr 

h 

c 

o 

>. 

•C 

o 

a 

o 

>* 

0 

C 

•H 

Li 

a 

■H 

0 

•* 

H 

c 

0 

> 

a 

0 

4> 

r-l 

c 

CL 

* 

a 

0 

a 

• 

o 

0 

•M 

0 

0 

H 

« 

o 

2 

-rl 

X 

0 

H 

•C 

A 

9 

*< 

JC 

rj 

a 

M 

s 

»■— 

H 

4-1 

O 

■o 

R 

[•] 

Ok  Ok  Ok 
Ok  Ok  Ok 
Ok  Ok  Ok 
Ok  Ok  Ok 
Ok  Ok  Ok 
Ok  Ok  Ok 


Ok  O  N 

Ok 

Ok 

Ok 

Ok 

Ok 


O  Ok  O  O  O  o  • 
o  Ok  o  00 


0H 

r* 

CO 

o 

«- 1 

kr 

« 

o 

o 

n 

l 

o 

o 

♦ 

+ 

+ 

l 

+ 

+ 

+ 

H 

H 

H 

H 

H 

H 

Ov 

r-l 

« 

n 

r4 

n 

CO 

*M 

n 

r- 

w 

n 

N 

H 

O 

CO 

«o 

H 

00 

r-« 

•H 

n  o 


s  s 

t*  a 


••4  n  n  v 


H  P 

s  s 

to  *a 
(W  H  s 


m  H 
£  K 


(V)  selected  PRESS  RETURN  TO  CONTINUE 


Specific  Information 


1.  The  input  data  required  for  this  program  for  selection 
of  target  vulnerability  data  are: 

SELECTION  chooses  means  of  entering 

target  data: 

1  through  10  if  limits  are  exceeded  asks 

user  to  select  again 

1  through  8  uses  predefined  files  of 

generic  ship  types 

9  uses  a  file  predefined  by  the 

user 

10  user  defines  ships  Operational 

Attributes  (OAT) 

This  data  is  entered  based  on  the  means  selected  to 
enter  target  data. 

FILENAME  appropriate  file  name 

OPERATING  DEPTH 

feet  submarine 

HULL  RADIUS 

feet  submarine  or  surface  ship 

COLLAPSE  DEPTH 

feet  submarine 


HULL  DEPTH 
feet 

OAT  # 

OAT  NAME 

8  characters 

ENVIRONMENT  MODEL 
1 

2 

3 

4 

5 

6 

7 

8 

9 

10 

11 

12 

110 


surface  ship 
only  25  OATS /TARGET 


used  only  as  an  identifier  in 
output 


translational  body  velocity, 
ft/sec 

excessive  impulse,  ft-psi 

energy  flux  density,  ft-psi 

overpressure,  psi* 

electromagnetic  pulse,  v/m 

neutron  fluence  form  1  MeV 

2 

equivalent,  n/cm 
total  ionizing  dose,  rads  (SI) 
peak  gamma  dose  rate,  rads 
(SI) /sec 

2 

total  x-ray  fluence,  cal/cm 

prompt  gamma  dose  (direct  and 

scattered) ,  rads  (SI) 

tissue  ionizing  dose,  rems 

2 

thermal  exposure,  cal/cm 

environment  level  for  10% 
impairment 


190 


environment  level  for  90% 
impairment 


DAMAGE  ACCUMULATION  MODEL 

1  Multiplicative  -  personnel  and 

aircraft 

Additive  -  seaworthiness  from 
blast  structural  damage 
or  deunage  from  total 
gamma  dose 

Maximum  -  mobility,  weapon 

delivery,  communication 
and  sensor  from  blast 
mechanical  damage  or 
electrical  damage  from 
gamma  dose  rate 

expected  time  to  repair  linear 
multiplier,  ETR  =  Ae**^®51  (if 
unknown  use  zero  and  disregard 
ETR  output) 

maximum  impairment  for  repair 
at  sea  ETR  =  »  for  I  >  IMAX 

This  information  must  be  entered  for  every  case. 

YIELD  (KT)  Kilotons 

HEIGHT  OF  BURST  *FT)  Feet  negative  number 

indicates  an  underwater 
burst.  If  999  entered 
for  HOB,  optimum  is 
selected  for  i.nput  psi 


2 


3 


A 


IMAX 


e 


PSI  LEVEL  TO  OPTIMIZE  PSI  if  less  than  1  or  greater 

than  100  will  ask  for 
level  again 

GROUND  RANGE  (FT)  Feet  distance  from  target  to 

burst  ground  zero 

TIME  (MIN)  Minutes  current  simulation  time 

used  to  update  ETR  (use 

zero  if  no  ETR  data) 

2.  Output  data  consists  of: 

o  A  repeated  display  of  input  target  data 
o  A  repeated  display  of  input  weapon  data 

o  A  listing  of: 

OAT  # 

OAT  NAME 

ENVIRONMENT 

ENVIRONMENT  LEVEL 

AVAILABILITY 


identifier 

identifier 

environment  for  which  this  OAT 
is  tested 

actual  level  of  environment 
the  OAT  experience*' 
availability  of  this  OAT 
remaining  (in  percent) 
estimated  time  to  repair  this 
damage 

infinity  =  999999 


ETR 


I. 


INTRODUCTION 


A.  Purpose 

The  purpose  of  this  Section  is  to  describe  two  versions  of 
NUCDAM  which  have  been  implemented  on  the  Hewlett  Packard  HP9845 
computer;  to  provide  complete  instructions  to  the  user  for  opera¬ 
tion  of  both  versions  of  the  code,  including  sample  dialogues; 
and,  finally,  to  establish  a  baseline  configuration  for  control 
purposes. 

B.  Definitions 

Two  versions  of  NUCDAM  have  been  developed  for  the  HP9845, 
called  the  Fleet  Model  and  the  Analytical  Model.  Fully  described 
below,  the  Fleet  Model  is  designed  for  efficient  use  in  a  tacti¬ 
cal  environment ,  while  the  Analytical  Model  is  intended  to  be 
employed  as  a  development  tool. 

C.  Design  Philosophy 
1.  Fleet  Model 


This  model  is  designed  for  maximum  efficiency  and  ease  of 
operation.  Demands  for  user  selection  of  variable  inputs  have 
been  minimized.  Target  data  are  taken  from  input  files  which 
have  been  pre-loaded  into  the  memory  along  with  the  main  program 
for  U.S.  and  Soviet  surface  ships,  carriers  and  submarines. 
Nevertheless,  provisions  exist  for  the  user  to  override  these 
data  and  furnish  his  own,  should  this  become  necessary.  Tech¬ 
nical  data  have  been  cut  to  a  minimum  to  avoid  distracting  or 
confusing  users  interested  only  in  the  bottom  line.  Thus,  the 
output  of  this  model  contains  verbal  descriptions  of  platform 
damage  rather  than  tables  of  data. 
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2. 


Analytical  Model 

This  model  presents  all  of  the  input  and  output  data  avail¬ 
able  in  NUCDAM  and  allows  the  user  complete  freedom  to  modify 
them  as  necessary.  The  user  has  the  option  to  employ  existing 
data  files  or  to  generate  his  own.  Standard  input  procedures 
have  been  streamlined  so  that  only  half  the  normal  nuntoer  of 
entries  is  required.  This  is  accomplished  by  pre-selection  of 
damage  accumulation  and  repair-time  parameters.  Again,  this 
pre-selection  may  be  overridden  by  the  user  should  he  so  desire. 

D.  Limitations 

Several  functions  could  be  added  to  this  version  of  NUCDAM 
but  do  not  reside  in  it  at  present.  It  is  important  to  recognize 
that  these  features  are  not  presently  available: 

o  Bottom-reflection  of  underwater  shock 
o  Underwater  shock  from  a  surface  burst 
o  Electromagnetic  pulse  from  a  high- 
altitude  burst 
o  Fireball  blackout 

o  Acoustic  reverberation  (BLUEOUT)  from 

underwater  or  surface  bursts 
Residual  radiation  from  base  surge  and  pool. 


o 


II.  FUNCTIONAL  DESCRIPTION  OF  THE  FLEET  MODEL  OF  HP9845  NUCDAM 

This  model  is  intended  to  be  used  for  rapid  estimates  of 
damage  to  fleet  units  subjected  to  nuclear  detonations.  To 
maximize  simplicity  of  input  procedures,  the  following  data  have 
been  pre-loaded  on  the  tape  cassette: 

Vulnerability  and  repair  time  data  for  O.S. 
and  Soviet  cruisers  (destroyers,  carriers, 
submarines .and  auxiliary  ships).  The  data 
actually  used  are  published  in  a  separate 
document . 

Yields  and  burst  heights /depths  of  U.S.  and 
Soviet  weapons.  These  are  tabulated  as 
UNCLASSIFIED  examples  which  can,  on  request, 
be  changed  to  actual  data  on  a  SECRET, 

RESTRICTED  DATA  tape  cassette. 

By  use  of  preloaded  data,  the  user  need  only  enter  the  target 
type  (OAT  file  name) ,  weapon  selection,  horizontal  range,  and 
submarine  keel  depth. 

Despite  the  high  degree  of  pre-loading  of  data,  the  user, 
nevertheless,  retains  flexibility  to  vary  all  of  the  input  data 
if  he  is  willing  to  take  the  time.  Vulnerability  levels  can  be 
changed  in  NUCDAM  Command  Option  2.  An  entire  new  file  can  be 
created  by  running  the  NUCDAM  Analytical  Model,  which  is  des¬ 
cribed  below,  recording  the  file  on  tape,  then  reloading  the 
NUCDAM  fleet  Model  and  running  it  with  the  newly  created  file. 


Upon  initial  start-up  (press  run)  or  restart  (press  STOP, 
then  run)  five  NUCDAM  command  options  are  presented: 


HUCJRH  Co***nd  Options 

1.  Directory  of  target  files 

2.  Change  or  add  data  in  target  file 

3.  Assess  attack  on  target  fro*  file 

4.  Calculate  nuclear  environments 

5.  Quit  NUCDAH 


OPTION  1  informs  the  user  of  existing  target  OAT  files. 

OPTION  2  allows  the  user  to  change  any  data  in  a  target  OAT 
file,  or  to  add  data  (provided  the  file  is  not  full). 

QgTI0N  3  is  the  operational  damage  assessment  mode  of 

Fleet  NUCDAM.  Given  the  yield,  burst  height  and  horizontal 
range,  the  program  calculates  and  describes  the  damage 
suffered  by  the  platform  represented  in  the  target  OAT  file. 

OP*1011  .1  allows  use  of  the  code  to  calculate  nuclear  envi¬ 
ronments. 

9P^IOM  terminates  the  code  and  rewinds  the  tape.  Provided 
the  computer  has  not  been  turned  off,  NUCDAM  can  be 
restarted  by  pressing  RUN. 

As  with  other  versions  of  NUCDAM,  the  program  calculates 
degradation  of  five  different  combat  capabilities,  known  as 
operational  attributes  (or  OATs)  using  scanoard  algorithms.*  The 
resulting  degradation  is  then  converted  to  a  time-to-repair , 
which  is  used  to  generate  a  verbal  damage  description. 


See  Reference  1. 
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NUCDAM  impacts  5  OATs  with  selected  items  from  a  list  of  12 
environments,  depending  on  applicability.  X-rays  are  not 
included  in  any  atmospheric  explosion  environment.  The  remaining 
11  apply  to  the  various  OATs  as  follows: 


Weapon  Comm.  Seawor- 

Pe livery  t  Sensors  Mobility  thiness  Personnel 


Body  Velocity  X 

Excess  Impulse 
Energy  Flux 
Air  Blast  X 

EMP  X 

Neutrons  X 

Total  Gamma  X 

Gamma  Dot  X 

Total  Prompt  X 

Tissue  Dose 
Thermal  X 


X  X 

* 

X 

** 

X 

x  X  x  X 

X 

X 

X 

X 

X 

X 

x  X 


** 


Submarines  only 
Surface  ships  only. 


NOTE:  Submarine  OATs  are  Weapon  Delivery,  Mobility  and 
Seaworthiness  only. 


TABLE  1 .  Permitted  Environments  for  Target  OATs 


If  the  target  is  a  submarine,  personnel  and  communications 
are  omitted  and  only  the  three  remaining  OATs  are  addressed  in 
the  damage  calculation. 
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Degradation  of  each  OAT  is  calculated  for  each  applicable 
nuclear  environment.  The  program  then  selects  the  largest 
degradation  of  each  OAT,  calculates  the  associated  repair  time, 
and  releases  a  statement  to  be  printed  out,  which  describes  the 
damage  and  extent  of  non-availability  of  the  OAT.  For  example,  . 
if  weapon  delivery  were  degraded  35%  by  air  hlast,  10%  by  gairma 
dot  and  20%  by  thermal  radiation,  only  the  blast  damage  is 
reflected  in  the  printed  statement. 

Each  OAT  has  preioaded  repair  time  parameters  (A  and  I  MAX) 

* 

as  in  standard  NUCDAM.  If  degradation  is  less  than  10%,  the  OAT 
is  treated  as  undamaged,  and  no  statement  regarding  the  OAT  will 
appear  in  the  output.  If  all  OATs  are  undamaged,  the  words  "HO 
DAMAGE  SUSTAINED"  will  be  printed.  If  degradation  is  greater 
than  IMAX,  the  words  "OUTSIDE  HELP  REQUIRED"  are  printed,  except 
in  the  case  of  seaworthiness  and  personnel.  If  degradation  is 
between  10%  and  IMAX,  the  statement  "UNAVAILABLE  FOR  <ETR)  HOURS" 
will  be  printed,  but  only  once  for  each  OAT,  corresponding  to 
maximum  degradation  from  all  applicable  environments.  Repair 
times  are  rounded  to  the  nearest  half  hour.  The  level  of  the 
environment  responsible  for  the  maximum  degradation  of  each  OAT 
is  also  printed  out. 

The  program  contains  provisions  to  tailor  damage  descrip¬ 
tions  and  limitations  as  to  OAT  types  for  different  targets. 

Thus,  the  weapon  delivery  capability  of  an  aircraft  carrier  is 
described  in  terms  of  its  ability  to  operate  aircraft,  and  com¬ 
munications /sensors  and  personnel  OATs  are  not  included  in  the 
OAT  files  of  submarines. 


Tf - 

See  Reference  1. 
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III.  FUNCTIONAL  DESCRIPTION  OF  THE  ANALYTICAL  MODEL  OF  HP9845 


NUCDAK 

This  m>del  is  intended  for  a  wide  variety  of  calculations, 
and  is  capable  of  being  further  modified  to  suit  the  needs  of 
users.  At  present  it  carries  out  the  basic  function  of  finding 
the  degradation  of  the  combat  capabilities  or  OATs  (operational 
attributes)  of  targets  as  described  in  target  OAT  files.  Inputs 
and  displays  show  all  relevant  data,  and  changes  can  be  made  with 
ease. 


This  version  of  NUCDAM  differs  from  its  predecessors  in  that 
input  procedures  have  been  simplified.  Depths  have  replaced 
negative  heights;  submarine  keel  depth  is  a  part  of  the  dialogue, 
rather  than  embedded  in  a  file  which  must  be  changed;  a  separate 
routine  to  edit  a  target  OAT  file  has  been  added;  permitted 
environments  have  been  ‘defined  in  accordance  with  Table  1,  above; 
and  the  amount  of  required  input  data  for  each  OAT  has  been 
halved. 

Review  of  Reference  1  indicates  that  repair  time  parameters 
and  damage  accumulation  models  are  target-specific.  They  are 
considered  to  be  the  best  available  and  unlikely  to  be  soon 
replaced.  Thus  it  seems  unreasonable  to  require  the  user-analyst 
to  select  values  for  A,  IMAX,  and  the  damage  accumulation  model 
each  time  an  OAT  entry  is  made.  Hence  the  data  and  guidance 
contained  in  Reference  1  have  been  transformed  into  a  set  of 
selection  rules  and  added  to  the  input  logic  of  the  Analytical 
Model.  These  parameters  are  selected  automatically  by  the 
program,  leaving  the  user  to  input  only  the  damage  model,  110  and 
190,  thus  appreciably  simplifying  the  task  of  creating  target  OAT 
files.  Should  the  user  wish  to  alter  the  program-selected  values 
of  these  parameters,  this  is  still  possible  by  changing  the  data 
in  the  file  after  initial  file  creation  (see  *7  in  Users  Guide 
below) . 


Upon  initial  startup  (press  RON)  or  restart  (press  STOP, 
then  RUN)  four  NUCDAM  command  options  are  presented: 


_ MUCPAH  CoMMWd  Option* _ 

1.  Directory  of  OUT  files 

2.  Enter  OAT  data  or  file  and  run 

3.  Purge  existing  OAT  file 

4.  Quit  NUCDAM 


OPTION  1  inf  ones  the  user  of  existing  target  OAT  files. 

OPTION  2  is  for  performing  actual  damage  assessment 
calculations,  changing  data  in  existing  files  or  creating 
new  files. 

OPTION  3  allows  the  user  to  delete  unwanted  target  OAT 
files. 

OPTION  4  terminates  the  code  and  rewinds  the  tape.  Provided 
the  computer  has  not  been  turned  off,  NUCDAM  can  be 
restarted  by  pressing  RUN. 

After  selection/creation  of  the  target  OAT  file-,  the  program 
takes  the  user  through  a  brief  interactive  dialogue  in  which  the 
weapon  parameters  are  selected.  The  program  then  calculates  the 
degradation  of  every  OAT  for  every  environment  specified,  and 
prints  the  results. 
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IV.  USER’S  GUIDE  AND  SAMPLE  DIALOGUE  FOR  THE  FLEET  MODEL  OF 
NUCDAM 

NOTE:  All  computer-generated  printouts  are  preceded  by  C:.  All 
typing  by  the  user  is  preceded  by  **:.  Quotation  marks, 
where  shown,  must  be  typed.  Statements  in  parentheses  are 
not  typed.  RUN,  EXECUTE  and  CONT  are  keys  on  the  HP9845 
keyboard. 


*1 


U:  (insert  tape  cassette  in  right  hand  (T15)  drive) 

U:  GET  "NUC — F"  EXECUTE  (wait  for  square  to  disappear  on 

screen) 

U:  RUN 


NUCDRM  Command  Options 

Directory  of  target  files 
Change  or  add  data  in  target  file 
Assess  attack  on  target  from  file 
Calculate  nuclear  environments 
Quit  NUCDAM 


U:  1  CONT 

BLR*  BLCD  BLSS  BLCV 

9R°S  ORCV  ORCD  ORSS 


File  names  are  as  follows: 

BL  BLUE 'friendly 

OR  ORANGE'eneay 

CV  Carrier 

CD  Cruiser'destroyer 

SS  Submarine 

RX  Auxiliary 

OS  OSCAR  class 
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.4»"W 


./.»-“  •-  v  -•-  «**- 


Press  CONT  to  continue 
CONT 


HUCPAH  Comnd  Options 

1.  Directory  of  target  filet 

2.  Change  or  add  data  in  target  file 

3.  Attest  attack  on  target  fro a  file 

4.  Calculate  nuclear  enuironaentt 
3.  Quit  NUCDAM 


U: 

C: 

U: 

C: 

C: 

U: 

C: 


2  CONT  {if  3  see  *2  below) 

Target  OAT  file  name  {4  characters  maximum; 
to  exit,  D  for  directory  assistance) 

(Enter  file  name)  CONT 

Displays  the  target  OAT  file  just  selected 
OAT  you  wish  to  change/add  (up  to  20  total) 
exit) 

(Enter  OAT  number)  CONT 


CHAHGE^RDP  OPTIONS 

1 .  OAT  Naae 

2.  Environment  Model 

3.  110 

4.  190 

3.  All  OAT  Data 
6.  Exit  Change  Mode 


C 

O 

C 

O 


Enter  menu  option  (1  to  6) 
1  CONT 

Enter  OAT  name: 

(Enter  OAT  name)  CONT 


press  CONT 


(type  0  to 
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U: 

C: 


2  CONT 


1.  P«*k  body  velocity 

2.  Excess  impulse 

3.  Energy  flux 

4.  Peek  sir  overpressure 

5.  Electromagnetic  pulse 

6.  Neutron  fluence 


Environments 


<EHP> 


?.  Total  gamma  dose 
8.  Peek  geese  dose  rete 
18.  Prompt  gemme  dose 

11.  Tissue  dose 

12.  Thermel  fluence 


C:  Enter  environment  model  (1  to  12) 

U:  (Enter  environment  model  number)  CONT 


0:  3  CONT 

C:  Enter  110 

0:  (Enter  110)  CONT 


0:  4  CONT 

C;  Enter  190 
0:  (Enter  190)  CONT 


0:  5  CONT 

(Follow  the  same  dialogue  as  in  Options  1-4  above) 

C:  OAT  you  wish  to  change/add  (type  0  to  exit) 

U:  (Continue  until  all  required  changes  have  been  made) 

U:  0 

C:  Save  to  tape  (Y/N)? 

U:  Y  (if  N  skip  to  *3  below) 

C:  New  target  OAT  file  name  (4  characters  maximum;  press 

CONT  to  exit) 

0:  (Enter  new  file  name) 

(skip  to  *2  below) 


3  CONT  (assess  attack  on  target  from  file) 

Target  OAT  file  name  (4  characters  maximum;  press  CONT 
to  exit,  D  for  directory  assistance) 

(Enter  file  name)  CONT 

(If  target  is  a  submarine)  Enter  keel  depth  (0  to 
(collapse  depth  -1) ,  ft. 

(Enter  keel  depth)  CONT 

Weapon  Selection 

1.  Known  BLUE 

2.  Estimated  RES 

3.  Arbitrary 


Enter  weapon  selection  (1  to  3) 

1  (or  2)  CONT  (if  3  see  *4  below) 
(1)  12\ 


11us-l 
11 us-2 
11  us-3 
11 us-4 
iWs-5 
1 1  us-4 
11 us-7- 
llus-8 
1 1  us-9 
1 1  us-18 


Yield 


18 

180 

188 

188 

588 

588 

588 

1888 

1888 


Yield  HOB 


-008 

8 

588 

-50'i 

b 

1888 

-1088 

0 

2888 


Gener-I 
Cener-2 
Gener-3 
Gener-4 
Gener-5 
Gener-G 
Cener-7 
Jtntr-7 
Gere'— 8 
Ctner'i? 


Enter  weapon  number  (1  to  10) 
(Enter  weapon  number)  CONT 


3  CONT 

Enter  yield  (1  to  10,000  kt) 

(Enter  yield)  CONT 

Enter  height  of  burst  (-30,000  to  200 
(Enter  height  of  burst)  CONT 
Enter  ground  range  (1  to  50,000  yd) 
(Enter  ground  range)  CONT 


L. 

tv’ 

& 

C: 

Current  time  (in  24-hr  format)? 

& 

U: 

(Enter  time)  CONT 

R 

C: 

Display  to  CRT  or  printer  (C/P)? 

r> 

0: 

(Enter  C  or  P)  CONT 

F>.* 

V-.  V 

C: 

(Sample  printout) 

»  *• 

k* 

Target: 

BLCB 

1 

Yield: 

200  kt 

yy: 

HOB: 

0  ft 

CR: 

3000  yd 

.4. 

Environ** nt  Level 


Operational  lapairaent 


4.66E+00  pti 
4.66E+00  psi 
3.55E+01  cal/sq  ci 


Unable  to  fire  weapons  for  £  hours 
Radar  /Com  not  available  for  9  hours 

Exposed  topside  pers  suffering  serious  3rd  degree  burns 


i 

* 


C: 

0: 

C: 


Display  all  environment  levels  (Y/N)? 
Y  (or  N)  CONT 

Environaent  Level _ 


Overpressure 

EMP 

Neutrons 
Tot  gmaaa 
Gaaaa-dot 
Tissue  dose 
Theraal 


4.6£  psi 
2917  volts/’a 
9.«E+00  n/sq  ca 
17.44  rad<Si> 
2.38E+06  radCSi>/sec 
35.38  rea 
35.49  calssq  ca 


r: 


C:  Another  run  With  the  same  target  (Y/N)? 

U:  N  CONT  (if  Y  reenter  dialogue  at  *3  above) 

C:  More  cases  (Y/N)? 

U:  Y  (or  N)  CONT 

(If  Y  reenter  dialogue  at  *2  above) 

(If  N  reenter  dialogue  at  *1  above) 


C-13 


V.  USER'S  GUIDE  AND  SAMPLE  DIALOGUE  FOR  THE  ANALYTICAL  MODEL  OF 
HP9845  NUCDAK 

NOTE:  All  computer-gene  rated  statements  are  preceded  by  C: .  All 
typing  by  the  user  is  preceded  by  U: .  Quotation  marks, 
where  shown,  must  be  typed.  Statements  in  parentheses  are 
not  typed.  RUN,  EXECUTE  and  CONT  are  keys  on  the  HP9845 
keyboard. 


U: 

U: 


*1 


U: 

C: 


(Load  cassette  in  right  hand  tape  drive  (T15)) 
GET  "NUCDAM"  EXECUTE 

(Wait  for  square  to  disappear  on  screen) 

RUN 


_ MUCDRH  Command  Option* _ 

1.  Directory  of  ORT  file* 

2.  Enter  ORT  data  or  file  and  run 

3.  Purge  existing  ORT  file 

4.  Quit  NUCDRR 


U:  1  CONT 

C: 


ILRX 

BLCB 

BLSS 

BLCV 

OROS 

OkCV 

ORCB 

ORSS 

File  names  ire  as  follows: 

BLRX  BLUE  Auxiliary 

BLCB  BLUE  Cruiser/Destroyer 

BLCV  BLUE  Carrie.- 

BLSS  BLUE  Submarine 

ORCD  ORRNCE  Crui ser/’Destroyer 

ORCV  ORRNCE  Carrier 

OROS  ORRNCE  Submarine,  OSCRR  Class 

ORSS  ORRNCE  Submarine 


V 


GCK^TJ27CTI  •  :  ■>  T??L»vr 


*  '  «'^ *1  1A”*_V 


U: 

C: 

*2  0: 
C: 

Or 

Cr 

0: 

C: 

*3  0: 

*3.1  C: 
U: 
C: 

0: 

C: 

0: 

C: 

Os 

C: 

C: 

0: 

C: 

♦4  O: 

C: 

0: 


2  CONT 

Existing  unit  (Y/N)  ? 

Y  CONT  (If  N  see  *9  belov) 

Target  OAT  file  name  (6  characters  maxima;  press  CONT 
to  exit)? 

(Enter  file  nane)  CCNT 

(for  submarine  target)  Enter  keel  depth  (0  to  (collapse 
depth  -1)  ft) 

(Enter  keel  depth)  CONT 

Do  you  want  to  change  any  of  the  prestored  data  (Y/N)? 

N  CONT  (If  Y  see  *7  below) 

Enter  yield  (1  to  10,000  kt) 

(Enter  yield)  CONT 

Enter  height  of  burst  (-30,000  to  200,000  ft);  (if  sub¬ 
marine  target)  Enter  depth  of  burst  (0  to  30,000  ft) 
(Enter  height/depth  of  burst)  CONT 
Current  time  (in  24-hr  format)? 

(Enter  time)  CONT 

Display  to  CRT  or  printer  (C/P)? 

C  (or  P)  CONT 
(Prints  output) 

Save  output  data  on  tape  (Y/N)  ? 

N  CONT  (if  Y  see  *8  below) 

Another  run  with  the  same  target  OAT  file  (Y/N)? 

Y  CONT  (if  N  see  *5) 

Do  you  want  to  change  any  of  the  prestored  data  (Y/N)? 
N  CONT  (reenter  dialogue  at  *3)  (if  Y  see  *7  below) 


*5  D:  N  CONT  (no  more  runs  with  the  current  target  OAT  file) 

C:  More  cases  (Y/N)? 

0:  Y  CONT  (if  N  see  *6) 

C:  Existing  unit  (Y/N)? 

U:  (Reenter  dialogue  at  *2) 
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*6  U:  M  CONT  (no  more  cases  to  run) 


C: 


HUCDRH  Ce»»nd  Options 
Directory  of  ORT  files 
Enter  ORT  data  or  file  and  run 


3.  Purge  existing  ORT  file 

4.  Quit  NUCDAM 


U:  (Reenter  dialogue  at  *1) 


*7  U:  Y  CONT  (exercise  option  to  change  prestored  target  OAT 

data) 

C:  Display  to  CRT  or  printer  (C/P)? 

0:  C  (or  P)  CONT 

C:  Prints  out  prestored  OAT  data  for  selected  file 

C:  Press  CONT  to  continue 

«•  CONT 

C:  OAT  you  wish  to  change/adtl  (1  to  maximum  number  OATs 

but  not  store  khan  20.  If  more  than  20  OATs  are 
required  a  nett  OAT  file  (see  *9  below)  must  be  created) 

U:  (Enter  OAT  number*  CONT 


CHRNGExRDD  OPTIONS 

1.  ORT  Name 

2.  Environment  Model 

3.  lie 

4.  198 

5.  Damage  Accumulation  Model 

6.  R  (repair  tine  parameter) 

7.  iMfiX 

8.  Rll  ORT  da\a 

9.  Exit  change  mode 


U:  (Enter  option  as  follows: 

1^  (self-explanatory) 

2  (environment  model) 
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C: 


1. 

2. 

3. 

4. 

5. 

6. 


Environment 

Peak  body  velocity 

7. 

Excess  iapulse 

8. 

Energy  flux 

18. 

Peak  ai r  overpressure 

11. 

Eiectroaagnetic  pulse 

<ENP)  12. 

Neutron  fluence 

» _ _ 

Total  gaaoa  dost 

Ptak  gaaoa  dose  /~at  t 
Prompt  gaaoa  dose 
Tissue  dose 
Theraal  fluence 


D:  3  or  4  CI10  or  190:  environmental  levels  corresponding 

to  onset  of  damage  (10%  degradation)  or  nearly  complete 
damage  (90%  degradation) ) 

6  or  7  (A  or  I  MAX:  repair  time  for  50%  degradation,  or 
maximum  degradation  repairable  on-board) 

8,  9  (self-explanatory) 

C:  Save  to  tape-file  (Y/N)? 

0:  Y  CONT  (Skip  to  *8.1)  (if  N  reenter  dialogue  at  *3.1) 


*8  0:  Y  CGNT  (save  target  OAT  file  to  tape) 

*8.3.  C:  Oi  tout  file  name  (6  characters  maximum;  press  CONT  to 

exit) ? 

3:  (Appropriate  file  name)  CONT 

C:  Another  run  with  the  same  target  OAT  file .  fY/N)  ? 

U:  (Reenter  dialogue  at  *4) 


*9  U:  N  CONT  (user  will  create  a  new  target  OAT  file) 
C:  Is  this  unit  a  ship  or  a  submarine  (SHIP/SOB)? 

0:  SHIP  (if  SUB  see  *11  below)  CONT 

C:  Enter  hull  radius  (1  to  100  ft) 

U:  (Enter  one  half  the  beam)  CONT 

C:  Enter  draft  (0  to  200  ft) 

U:  (Enter  draft)  CONT 

C:  Enter  number  of  weapon  delivery  OATs  (0  to  8) 
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U:  (Enter  number  of  DATs  desired  to  describe  surface  ship 

weapon  delivery  vulnerability  to  environments  selected 
froai  the  following:  peak  body  velocity#  air  blast# 
electromagnetic  pulse#  neutron  fluence#  total  gamma 
dose,  peak  gamma  dose  rate,  prompt  gamma  dose#  and 
thermal  fluence)  COWT 

C:  Data  for  OAT  #1#  WD1 

C:  Environments  for  HD  OATs  (prints  list  of  permitted 

environaents;  e.g.  #  excess  impulse  is  not  applicable  to 
surface  ships;  TREE  effects  are  not  applicable  to 
submarines;  tissue  dose  is  not  applicable  to  any  OATs 
except  personnel#  etc.) 

C:  Enter  environment  number 

0:  (Eater  number  from  list  of  permitted  environments)  COHT 

C:  Enter  110  (in  appropriate  units) 

U:  (Enter  environment  corresponding  to  onset  of  damage) 

CONT 

C:  Enter  190  (in  appropriate  units) 

D:  (Enter  environment  corresponding  to  nearly  complete 

damage)  COWT 

C:  Prints  complete  line  of  data  just  entered  by  user,  plus 

computer-selected  data  on  repair  times  and  damage  accu¬ 
mulation.  Should  the  user  desire  to  vary  any  of  these 
parameters#  he  can  do  so  by  typing  T  at  *3  above  after 
this  OAT  file  is  complete.  It  will  then  be  possible  to 
change  any  (or  all)  of  the  program-selected  elements  in 
the  target  OAT  data  file. 

C:  Are  the  data  for  this  OAT  correct  (Y/N)? 

Vz  Y  COHT  (if  N  return  to  *10) 

C:  Data  for  OAT  #2#  WD2#  etc.  (through  WD8  in  this  case) 

C:  Enter  number  of  mobility  OATs  (0  to  2) 

0:  (Enter  number  of  OATs  desired#  up  to  2#  to  describe 

surface  ship  mobility  vulnerability  to  peak  body 
velocity  and  air  blast)  CONT  (Reenter  dialogue  at  *10) 

C:  Enter  number  of  seaworthiness  OATs  (0  to  3) 
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U:  (Enter  nuaber  of  OATs  desired,  op  to  3,  to  describe 

surface  ship  seaworthiness  vulnerability  to  peak  body 
velocity,  energy  flux,  and  air  blast)  (Reenter  dialogue 
at  *10) 

C:  Enter  nuaber  of  personnel  OATs  (0  to  3) 

0:  (Eater  nuaber  of  OATs  desired,  up  to  3,  to  describe 

personnel  vulnerability  to  air  blast,  tissue  dose 
(initial  nuclear  radiation) ,  and  thermal  radiation) 
(Reenter  dialogue  at  *10) 

C:  Enter  nuaber  of  communications/ sensors  OATs  (0  to  8) 

U:  (Enter  nuaber  of  OATs  desired,  up  to  8,  to  describe 

surface  ship  cnmannications/sensors  vulnerability  to 
peak  body  velocity,  air  blast,  electromagnetic  pulse, 
neutron  fluence,  total  gaama  dose,  peak  gaama  dose 
rate,  prompt  gaama  dose  ,  and  thermal  fluence)  (Reenter 
dialogue  at  *10) 

C:  Scve  to  tape  (Y/H)? 

U:  V  COST  (if  H  reenter  dialogue  at  *3.1) 

C:  Output  file  name  (6  characters  maximum;  press  COST  to 

exit) ? 

0:  (Enter  name  of  new  target  OAT  file  just  created). 

(NOTE:  It  is  possible  to  specify  an  existing  file  name 
and  write  the  new  data  over  the  existing  data,  if 
desired)  COST  (Reenter  dialogue  at  *3.1) 

*11  U:  SUB  COST  (mer  desires  to  create  a  submarine  target  OAT 

file) 

C:  Enter  hull  radius  (1  to  100  ft) 

0:  (Enter  hull  radius  (half  the  beam))  CONT 

C:  Enter  collapse  depth  (100  to  10,000  ft) 

U:  (Enter  collapse  depth)  CONT 

C:  Enter  keel  depth  (0  to  (collapse  depth  -1) ) 


019 


U:  (Enter  keel  depth)  CONT 

(Reenter  dialogue  at  *10.  Note  that  there  is  only  one 
permitted  environment  for  each  of  three  OATs  for  submarines 
as  follows: 

OAT  ENVIRONMENT 

Weapon  Delivery  Body  velocity 

Mobility  Body  velocity 

Seaworthiness  Excess  impulse) 


APPENDIX  D 


VERSION  #5  USERS  GUIDE  (VAX  11/780) 


NWISS  NUCDAM  SYSTEM  USERS  MANUAL 


CHAPTER  1 

OVERVIEW 


1 . 1  INTRODUCTION 


The  NWISS  NUCDAM  SYSTEM  was  developed  to  work  in  conjunction 
with  the  Battle  Group  Training  Computer  Support  Facility  (BGJ*CSF) 
as  a  stand  alone  tactical  decision  aid.  The  BGTCSF  offers  the 
opportunity  for  tactical  engagement  training  through  a  computer¬ 
ized  warfare  simulation.  The  initial  BGTCSF  simulation  will  have 
no  nuclear  engagement  capability.  The  NWISS  NUCDAM  SYSTEM  will 
give  the  users  of  BGTCSF  the  option  of  having  some  tactical 
nuclear  capability  through  a  stand  alone  simulation  designed  to 
operate  within  the  BGTCSF  framework. 

The  purpose  of  this  report  is  to  document  the  activities 
associated  with  the  design  and  development  of  the  NWISS  NUCDAM 
SYSTEM  performed  by  KSC  under  Contract  DNA001-82-C-0288  during 
the  period  1  July  1982  through  15  November  1982.  These  activi¬ 
ties  involve  the  incorporation  of  the  NUCDAM  model  developed  for 
the  Naval  Nuclear  Warfare  Simulation  (NNWS)  into  a  user  friendly 
system  designed  to  be  compatible  with  the  BGTCSF. 

The  remainder  of  this  chapter  provides  an  overview  of  both 
the  NWISS  NUCDAM  SYSTEM  and  NUCDAM.  Chapter  2  documents  the 
NWISS  NUCDAM  SYSTEM  which  was  developed  under  this  contractual 
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effort.  Chapter  3  describes  the  use  of  the  data  BUILD  function 
to  create  the  data  files  to  be  used  in  a  wargame  exercise  which 
will  be  compatible  to  the  BGTCSF  data.  Chapter  4  is  a  student 
users  manual  which  describes  the  use  of  the  system  once  a  data 
file  is  available  and  the  BGTCSF  exercise  has  begun.  Appendix  A 
contains  a  brief  description  of  the  routines  developed  for  the 
NWISS  NUCDAM  SYSTEM.  Appendix  B  contains  FORTRAN  listings  of 
those  routines.  The  NUCDAM  routines  have  been  thoroughly 
documented  in  References  1,  2  and  3.  This  information  has  not 
been  repeated  in  this  document  and  the  interested  reader  is 
directed  to  those  references.  For  completeness  the  FORTRAN 
listings  of  the  NUCDAM  subprograms  have  been  put  in  Appendix  C. 

1.2  NWISS  NUCDAM  SYSTEM  DESCRIPTION 

The  NWISS  NUCDAM  SYSTEM  is  designed  to  provide  a  stand  alone 
nuclear  capability  to  the  BGTCSF  tactical  engagement  training 
simulation.  The  initial  BGTCSF  computerized  warfare  simulation 
offers  no  nuclear  capability.  The  NWISS  NUCDAM  SYSTEM  will 
provide  the  player  participating  in  the  tactical  engagement 
training  wargame  the  opportunity  to  examine  the  possible  effects 
of  the  use  of  tactical  nuclear  weapons  by  either  of  the  forces. 
The  NWISS  control  function  will  also  be  able  to  utilize  the 
information  from  the  NWISS  NUCDAM  SYSTEM  to  make  decisions  as  to 
the  effects  of  the  use  of  nuclear  weapons  if  it  is  decided  that 
their  use  is  to  be  employed.  Since  the  NWISS  NUCDAM  SYSTEM  will 
not  have  access  to  the  data  base  of  the  wargame  simulation,  there 
will  be  a  compatible  data  base  designed  to  allow  stand  alone 
analysis  in  real  time  during  the  wargame.  The  data  base  will  be 
designed  by  the  wargame  systems  analyst.  That  function  will 
decide  what  data  will  be  in  the  data  file  available  to  the  BLUE 


and  ORANGE  views.  It  may.be  that  both  views  would  use  the  same 
data  base  and  thus  know  everything  about  both  forces  or  each 
force  may  only  have  nuclear  damage  data  concerning  its  own  units 
or  each  force  might  have  accurr  ..  data  concerning  its  own  units 
and  questionable  intelligence  data  about  the  opposition 
vulnerability.  Real-time  data  is  entered  from  the  keyboard 
during  the  wargame  based  on  the  view  that  the  user  has. 

The  NWISS  NUCDAM  SYSTEM  is  designed  with  four  operating 
functions:  HELP,  BUILD,  TACAID ,  NUCDAM.  Each  of  the  functions 
will  be  described  separately  in  the  following  paragraphs. 

The  HELP  function  will  provide  interactive  user  documenta¬ 
tion  on  the  use  of  NUCDAM.  The  HELP  function  is  self  prompting 
and  self  directing.  The  HELP  function  can  be  called  at  any  time 
during  a  NWISS  NUCDAM  SYSTEM  session.  The  return  of  HELP  tc  any 
prompt  will  place  the  user  in  the  HELP  mode.  An  END  will 
terminate  the  HELP  session  and  return  to  the  prompt  from  which 
HELP  was  called. 

The  BUILD  function  will  allow  the  game  analyst  to  prepare  a 
data  file  of  the  platforms  (units  involved  in  the  wargame'  and 
the  OATs  (operational  attributes  of  the  platforms)  which  wii.  be 
used  in  the  wargame.  There  are  two  types  of  entries  in  the  BUILD 
function:  OATs  and  platforms.  The  BUILD  function  will  open  and 
close  the  data  files  as  requested. 

The  TACAID  function  is  a  tactical  decision  aid  to  the 
players  during  a  BGTCSF  wargame.  This  function  allows  the  player 
to  see  the  nuclear  environment  contours  (which  are  in  tabular 
form  in  this  version)  for  environments  of  interest  around  a 
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potential  nuclear  burst.  This  will  allow  the  player  to  determine 
the  effects  which  will  be  experienced  by  nearby  friendly,  neutral 
or  enemy  forces.  The  output  of  the  TACAID  function  will  be  plot 
data  in  tabular  form  which  can  eventually  be  plotted  when  appro¬ 
priate  hardware  is  available. 

The  NUCDAM  function  provides  specific  environment  and  damage 
level  data  for  a  given  platform  and  nuclear  detonation 
combination.  The  information  may  be  of  value  to  the  NWISS 
control  function  for  determining  the  damage  to  a  platform  if  a 
nuclear  weapon  is  fired  during  a  game.  It  also  will  be  of  value 
to  a  player  considering  the  use  of  a  nuclear  weapon.  This 
function  can  project  possible  environment  levels  and  damage 
experienced  by  a  specific  enemy,  neutral  or  friendly  platform. 

1.3  NUCDAM  DESCRIPTION 

The  Nuclear  Damage  Assessment  Module  (NUCDAM)  was  developed 
by  Kaman  Sciences  Corporation  to  be  used  in  the  Naval  Nuclear 
Warfare  Simulation  (NNWS)  for  calculating  damage  to  naval  units 
involved  in  tactical  nuclear  engagements  at  sea.  The  purpose  of 
NUCDAM  is  to  determine  the  degree  of  OAT  impairment  to  a  naval 
unit  that  has  been  subjected  to  the  effects  of  a  nuclear  burst. 
Damage  to  naval  units  from  a  tactical  engagement  is  determined  by 
calculating  the  nuclear  environment  based  on  the  weapon  yield  and 
weapon-target  geometry,  and  then  relating  the  calculated 
environment  to  damage  threshold  parameters  associated  with  the 
target  to  determine  the  degree  of  impairment  to  the  operational 
attributes  that  describe  the  naval  unit. 


The  nuclear  environments  which  have  been  incorporated  into 
the  model  are  underwater  shock  (including  bottom  reflection) ,  air 
blast  and  atmospheric  radiation  from  underwater  bursts,  and 
atmospheric  blast,  thermal,  initial  radiation  and  low  altitude 
EMP  from  air  or  surface  bursts.  Damage  predictions  are  made 
based  on  admittedly  subjective  data  which  is  described  in  Chapter 
3  where  the  use  of  the  BUILD  function  to  create  the  data  file  to 
be  used  in  a  wargame  exercise  is  described. 

The  nuclear  environment  models  in  NUCDAM  have  been 
thoroughly  documented  in  References  1,  2  and  3  and  will  not  be 
repeated  in  this  report.  The  interested  reader  is  directed  to 
these  references  for  a  complete  technical  discussion  of  the 
models  used  and  their  implementation. 


CtlAPTER  2 


NWISS  NUCDAM  SYSTEM 

2.1  INTRODUCTION 

The  purpose  of  this  chapter  is  to  describe  the  NWISS  NUCDAM 
SYSTEM  which  has  been  developed  for  use  with  the  BGTCSF  tactical 
engagement  simulation.  This  is  a  fully  interactive  user  friendly 
system  designed  to  run  in  conjunction  with  BGTCSF  as  a  stand 
alone  tactical  decision  aid.  The  basic  purpose  of  this  system  is 
to  provide  nuclear  environment  and  damage  data  to  the  commander 
that  finds  himself  in  a  tactical  nuclear  warfare  situation. 
General  information  concerning  the  environments  created  by  a 
nuclear  burst  will  be  presented  as  well  as  information  about 
specific  units  in  the  nuclear  vicinity.  This  system  is  designed 
with  four  operating  functions:  HELP,  BUILD*  TACAID  and  NUCDAM. 
A  request  for  a  keyboard  entry  will  always  be  prompted  by  > . 
During  any  function  a  prompt  answered  by  a  ?  will  result  in  a 
message  explaining  what  is  required  as  a  response  followed  by  a 
repeat  of  the  prompt.  Also  any  prompt  may  be  answered  by  a  HELP 
or  a  HELP  (qualifier)  which  will  result  in  the  activation  of  the 
HELP  function  which  may  then  be  terminated  by  END  resulting  in  a 
repeat  of  the  original  prompt.  QUIT  as  a  response  to  any  prompt 
will  cause  the  termination  of  the  current  operating  function.  A 
detected  erroneous  response  to  a  prompt  will  result  in  the  prompt 
being  repeated  or  the  function  being  recycled  to  a  logical 
position  in  the  processing. 


2.2  HELP  FUNCTION 


The  HELP  function  i6  designed  to  provide  interactive  user 
documentation  on  the  use  of  the  NWISS  NUCDAM  SYSTEM.  This  func¬ 
tion  is  activated  by  a  series  of  interactive  commands  which  will 
guide  the  user  through  the  use  of  this  system.  These  commands 
are: 


HELP 


HELP  HELP 


HELP  BUILD 


HELP  TACAID 


HELP  NUCDAM 


HELP  DATA 


The  basic  help  command  which  will 
direct  the  user  in  the  use  of  the 
HELp  function. 

This  HELP  directive  will  explain 
the  concepts,  general  flow  and  the 
use  of  the  NWISS  NUCDAM  SYSTEM. 

This  directive  will  describe  the 
BUILD  function  and  give  complete 
instructions  for  its  use. 

This  instruction  will  explain  the 
TACAID  function  and  give  step-by- 
step  directions  for  its  use. 

This  directive  will  outline  the 
NUCDAM  function  and  describe  the 
data  which  is  output. 

This  option  allows  the  user  to  see 
what  CAT  and  platform  names  are 
currently  on  the  data  file. 


The  processing  in  the  HELP  function  is 
Requests  are  made  by  the  user  and  information  is 


very  simple, 
returned  from 


predefined  data.  The  data  is  designed  to  be  self  prompting  and 
self  directing.  At  the  end  of  each  HELP  presentation  directions 
are  given  to  the  user  on  how  to  proceed. 

2.3  BUILD  FUNCTION 


The  BUILD  function  allows  the  game  analyst  to  prepare  a  data 
file  of  the  platforms  and  OATs  which  will  be  used  in  a  BGTCSF 
wargame  exercise.  There  are  two  types  of  entries  in  the  BUILD 
function:  platforms  and  OATs.  The  processing  during  this 
function  consists  of  data  file  creation  and  modification  based  on 
interactive  input  data.  All  responses  are  checked  for  possible 
errors  such  as  incorrect  type  or  out-of-range  conditions.  In 
case  of  a  detected  error  the  user  will  be  notified  and  given  a 
chance  to  correct  it.  The  file  creation  process  will  be 
logical!  checked  during  the  BUILD  function.  Each  OAT  and 
platform  name  must  be  unique  and  each  OAT  assigned  to  a  platform 
must  already  exist  on  the  data  file.  Error  conditions  must  be 
corrected  or  eliminated  before  processing  can  continue. 

The  data  file  created  by  the  build  function  is  a  random 
access  indexed  file  which  is  keyed  on  an  OAT/platform  indicator 
and  the  OAT/platform  name.  A  sequential  listing  of  the  OAT  and 
platform  n«.-mes  on  the  file  can  be  obtained  using  the  HELP  DATA 
coamand.  The  output  of  the  BUILD  function  is  a  data  file  which 
can  be  used  as  input  to  the  NUCDAM  function.  The  opening  and 
closing  of  data  files  is  handled  by  the  system. 

2.4  TACAID  FUNCTION 


The  TACAID  function  is  a  tactical  decision  aid  to  the  player 
during  a  BGTCSF  wargame.  The  intent  of  this  function  is  to 


D-8 


present  environment  contour  plots  resulting  from  a  nuclear 
explosion.  Due  to  hardware  limitations,  graphic  plots  are  not 
available  in  this  version.  Instead  the  data  is  presented  in  a 
tabular  from  which  may  be  used  for  plotting  and  eventually  used 
for  graphics  presentation  when  appropriate  hardware  becomes 
available. 

The  player  is  able  to  see  the  nuclear  environments  of 
interest  around  a  nuclear  burst  and  to  determine  the  possible 
environment  level  which  will  be  experienced  by  nearby  friendly, 
neutral  or  enemy  forces.  The  nuclear  environments  may  be 
examined  under  two  options:  RANGE  and  LEVEL.  Under  the  RANGE 
option  the  user  may  specify  up  to  6  environments  and  plot 
parameters  of  maximum  range  and  range  increment.  The  RANGE 
option  returns  data  suitable  for  environment  level  vs  range 
plots.  The  LEVEL  option  allows  the  user  to  specify  up  to  6 
environment  levels  for  which  radius  of  effects  for  each  environ-* 
went  level  ere  presented.  These  data  are  suitable  for  radius  of 
effect  contours  on  a  plot  board. 

2.5  NUCDAM  FUNCTION 

The  NUCDAM  function  provides  specific  environment  and  damage 
level  information  for  a  given  platform  and  nuclear  burst  combina- 
tion.  The  player  is  allowed  to  choose  the  appropriate  data  file. 
The  NUCDAM  function  may  then  be  queried  about  the  effects  cf  a 
nuclear  burst  on  one  of  the  defined  platforms  ir;  the  data  file. 
The  user  has  tne  option  of  specifying  the  relative  locations  of 
the  burst  and  the  platform  as  a  range,  or  the  absolute  locations 
may  be  specified  as  latitude  and  longitude  from  which  the  range 
is  calculated.  This  function  will  then  report  on  the  environment 


levels  experienced,  impairment,  availability  and  expected  time  to 
repair  (ETR)  of  each  OAT  assocfatea  *ith  the  platform. 

During  a  session  of  the  NUCDAM  function,  a  scratch  file  of 
damage  data  is  maintained.  The  purpose  of  this  file  is  to 
accumulate  damage  data  and  ETR  information  for  multiple  nuclear 
burst  environments  during  a  NUCDAM  function  session.  As  data  is 
requested  for  the  nuclear  bursts  affecting  the  requested  plat¬ 
forms,  the  damage  data  is  accumulated  on  the  scratch  file  for 
each  OAT  of  each  platform.  When  the  NUCDAM  function  is 
terminated,  the  file  is  scratched  and  the  damage  accumulation 
data  lost.  Thus  to  effectively  "zero  out"  the  damage  accumula¬ 
tion  data,  the  user  Kiy  terminate  and  then  reenter  the  NUCDAM 
function. 


CHAPTER  3 


BUILD  FUNCTION  USERS  GUIDE 

3.1  INTRODUCTION 

The  BUILD  function  is  a  data  file  utility  of  the  NWISS 
NUCDAM  SYSTEM  which  creates  and  Modifies  the  data  files  used  by 
the  NUCDAM  function.  This  utility  is  not  intended  to  be  used  by 
the  student  or  participant  in  a  BGTCSF  wargase  exercise.  The 
integrity  of  the  data  files  is  protected  by  a  BUILD  authorization 
code  which  is  required  before  the  user  is  allowed  into  the  BUILD 
function.  The  B^ILD  function  is  used  by  the  BGTCSF  wargawe 
analyst  to  create  a  data  file  which  is  compatible  with  the  BGTCSF 
data  base  and  the  purpose  of  the  wargase  exercise.  It  say  be 
that  the  purpose  of  one  exercise  would  be  served  by  one  data  file 
containing  all  of  the  nuclear  damage  data  which  would  then  be 
available  to  both  of  the  forces.  Another  wargamc  purpose  Might 
be  best  served  by  having  a  BLUE  VIEW  data  file  and  an  ORANGE  VIEW 
data  file  designed  by  the  wargaMe  analyst  to  restrict  the  know¬ 
ledge  of  each  view  to  some  realistic  level.  The  purpose  of  this 
chapter  is  to  guide  the  wargame  analyst  in  the  U6e  of  this 
function . 

3.2  DATA  FILE  HANPLING 

After  'riT-  j  the  NWISS  NUCDAM  SYSTEM  the  user  is  asked 

which  proc:  using  function  is  desired.  At  this  point  the  user  May 
request  the  BUILD  function.  Upon  selection  of  BUILD  the  user 
will  br  ^sked  for  the  user  authorization  code.  This  is  an 
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installation  parameter  which  will  be  provided  to  the  user  that  is 
authorized  to  create  and  modify  data  files  for  the  NtflSS  HUCDAM 
SYSTEM.  When  the  authorization  has  been  accepted,  the  user  will 
have  the  option  to  create  a  file  or  aodify  an  existing  file.  At 
this  point  the  user  must  specify  che  file  name  that  will  be  used. 
The  file  specification  has  the  form: 

device: (directory) filename. type; version. 

In  general  the  device  and  directory  specification  will  be 
default.  If  the  version  number  is  not  specified  the  latest 
version  will  be  selected  by  default.  If  a  data  file  is  already 
open  the  user  has  the  option  to  use  that  file  or  open  a  different 
file.  When  a  file  has  been  successfully  opened  the  user  will 
have  the  option  to  process  an  OAT  or  to  process  a  platform  or  to 
terminate  the  BUILD  function  with  END.  The  interactive  command 
structure  is  shown  below. 

ENTER  PROCESSING  OPTION  (HELP, BUILD ,TACAID,NUCDAH,END) 

>  (build) 

ENTER  BUILD  AUTHORIZATION 

>  (authorization) 

*****  THIS  IS  THE  BUILD  FUNCTION  ***** 

DO  YOU  WISH  TO  BUILD  A  NEW  FILE  OR  MODIFY  (NEW/MOD) 

>  (new  or  mod) 

ENTER  FILE  NAME 

>  (filename. type; version) 

FILE  (filename. typejversion)  HAS  BEEN  OPENED 

ENTER  OAT,  PLATFORM  OR  END 

>  (oat,  platform  or  end) 
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3.3  OAT  PROCESSING 


An  OAT  represents  an  operational  attribute  of  a  plat  font. 
An  OAT  name  Bust  be  unique  to  all  others  on  the  data  file.  An 
OAT  is  represented  by  an  alphanumeric  string  up  to  10  characters 
long.  If  an  OAT  record  already  exiscs  on  the  data  file  the  user 
has  the  option  to  modify,  delete  or  retain  the  record.  If  the 
record  exists  and  the  user  chooses  to  modify  the  record,  each 
parameter  of  the  OAT  is  presented  and  the  user  has  the  option  to 
enter  a  new  value  or  to  leave  it  the  same  with  a  null  return. 
The  user  is  prompted  through  the  parameters  for  each  record  which 
is  being  created  or  modified. 


Each  OAT  must  have  1  and  may  have  up  to  S  environments  which 
may  affect  its  performance.  There  are  6  parameters  associated 
with  each  environment. 


Each  OAT  of  a  platform  is,  in  general,  most  susceptible  to 
damage  from  one  environment  than  from  another.  While  the  DIMS 
HUCDAM  SYSTEM  has  allowed  up  to  5  damaging  environments  to  be 
associated  with  each  OAT,  it  is  not  expected  that  more  than  one 
or  two  will  be  used  for  most  OATs.  See  Reference  3  for  some 
example  data.  The  environment  is  defined  by  a  nuclear 
environment  code  shown  in  the  following  table: 


translation  body  velocity,  ft/sec 
excessive  impulse,  psi-sec 
energy  flux  density,  ft-psi 
atmospheric  overpressure,  psi 
electromagnetic  pulse,  v/m 
neutron  fluence  for  1  mev  equiv,  n/cm* 
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7  total  ionizing  dose,  rads (si) 

8  peak  gamma  dose  rate,  rads (si) /sec 

9  total  x-ray  fluence,  cal /cm* 

10  prompt  gamma  dose  (direct/ scattered) ,  rads (si) 

11  tissue  ionizing  dose,  rems 

12  thermal  exposure,  cal/cma 

13  surface  atmos  ovrprs  from  u/w  burst,  psi 

14  base  surge:  max  dose  rate,  rads/hour 

15  base  surge:  total  dose,  rads 

The  HUCDAM  damage  model  considers  the  weapon-target  geometry 
in  conjunction  with  specified  vulnerability  levels  to  calculate 
impairment  to  the  affected  OAT  from  intermediate  environments. 
When  an  environment  level  for  an  OAT  has  been  calculated,  the 
probability  of  OAT  impairment  is  determined  from  a  damage  or 
impairment  curve  which  is  assumed  to  be  linear  between  the 
vulnerability  values  specified  for  10%  and  90%  impairment.  For 
this  model  two  input  values  are  required:  an  environment  level 
associated  with  10%  impairment  and  an  environment  level  associ¬ 
ated  with  90%  impairment. 

The  NUCDAM  damage  accumulation  model  stems  from  the  ability 
of  nuclear  weapons  to  produce  damaging  environments  at  long 
ranges  from  the  detonation  point.  If  the  units  of  a  task  group 
are  spaced  far  enough  apart,  no  single  tactical  nuclear  weapon 
could  destroy  more  than  one  ship.  However,  the  damage  producing 
range  of  such  weapons  is  large  enough  that  a  unit  may  incur  some 
collateral  damage  as  a  result  of  an  attack  on  an  adjacent  unit  in 
the  task  group.  It  is  conceivable  that  a  unit  could  be  damaged 
to  the  point  of  combat  ineffectiveness  without  itself  ever  being 
the  target  of  an  attack.  The  damage  accumulation'  model  associ¬ 
ated  with  a  given  OAT  is  specified  by  one  of  the  following  codes: 
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TXT.T'X'Xn  '  i/JL-UL-J.' 


1  '  multiplicative  (personnel,  aircraft) 

2  additive  (seaworthiness) 

3  maximum  (mobility,  weapons,  communications,  sensors) 

When  a  target  is  damaged  by  a  nuclear  burst,  repair  of  the 
damaged  components  will  immediately  begin  in  an  attempt  to 
restore  as  much  as  possible  of  the  target's  capability.  The 
expected  time  to  repair  (ETR)  model  in  NUCDAM  is  based  on  several 
assumptions.  First,  the  ETR  model  ignores  the  fact  that 
identical  impairment  levels  may  have  different  ETRs  and  assumes 
that  for  any  OAT  the  ETR  is  a  direct  function  of  impairment. 
Second,  the  model  assumes  that  ETR  is  not  linear  with  impairment 
but  rather  exponential.  This  means  that  doubling  the  impairment 
will  square  the  repair  time,  which  implies  that  higher  levels  of 
impairment  will  generally  involve  more  serious  damage  to 
components  that  are  less  easily  repaired  or  replaced.  Finally, 
it  is  assumed  that  above  a  certain  level  of  impairment  no  repair 
will  be  possible  unless  the  unit  returns  to  port  to  restore  its 
functional  capability.  Thus,  for  the  ETR  model  two  input 
parameters  are  required:  the  ETR  linear  multiplier  and  the 
maximum  impairment  for  which  repair  can  be  made  at  sea.  If  ETR 
data  is  not  available,  a  null  return  will  disable  the  ETR  model. 

When  the  user  has  finished  entering  the  parameters  for  the 
OAT  being  processed,  the  data  will  be  displayed  and  the  user 
given  the  choice  of  saving  it  onto  the  data  file  or  scratching 
it.  The  interactive  input  prompts  are  shown  below. 

•ENTER  OAT,  PLATFORM  OR  END 

>  (oat) 

ENTER  OAT  NAME 

>  (oat  name) 
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ENTER  NUMBER  OF  ENVIRONMENTS 

>  (number  of  environments) 

ENTER  DATA  FOR  ENVIRONMENT  NUMBER  1 
ENTER  ENVIRONMENT  CODE 

>  (code  number) 

ENTER  LEVEL  FOR  10%  IMPAIRMENT 

>  (environment  level) 

ENTER  LEVEL  FOR  90%  IMPAIRMENT 

>  (environment  level) 

ENTER  DAMAGE  ACCUMULATION  CODE 

>  (code  number) 

ENTER  EXPECTED  TIME  TO  REPAIR  CONSTANT 

>  (etr  constant) 

ENTER  THE  MAXIMUM  IMPAIRMENT  PERCENTAGE 

>  (maximum  impairment) 

.  (repeated  for  each  environment) 

• 

(oat  name)  HAS  (number)  ENVIRONMENTS 
ENVIRONMENT  NUMBER  1  CODE  IS  (number)  -  (name) 

10%  IMPAIRMENT  LEVEL  IS  (environment  level) 

90%  IMPAIRMENT  LEVEL  IS  (environment  level) 

DAMAGE  ACCUMULATION  CODE  IS  (number)  -  (type) 

REPAIR  TIME  CONSTANT  IS  (repair  constant) 

MAXIMUM  IMPAIRMENT  PERCENTAGE  IS  (maximum  impairment) 
• 

.  (repeated  for  each  environment) 

• 

SAVE  THIS  DATA  ?  (YES  OR  NO) 

>  (yes  or  no) 

ENTER  OAT,  PLATFORM  OR  END 

> 
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3.4  PLATFORM  PROCESSING 


A  platform  represents  a  unit  in  a  task  group  or  a  target 
unit  which  consists  of  a  set  of  OATs.  A  unique  alphanumeric  name 
up  to  10  characters  is  assigned  to  each  platform  on  a  data  file. 
The  platform  is  associated  with  a  set  of  OATs  each  of  which  must 
exist  on  the  data  file.  Each  platform  may  be  associated  with 
from  1  to  50  OATs.  Each  platform  is  classified  as  one  of  four 
generic  types:  surface  ship,  submarine,  aircraft  or  land  target. 
A  surface  ship  will  have  associated  with  it  the  hull  radius  and 
the  hull  depth.  A  submarine  will  have  associated  with  it  the 
hull  radius  and  the  collapse  depth.  The  hull  radius  is  the  hull 
cross  section  radius  in  feet.  The  hull  depth  is  the  depth  of  the 
hull  of  a  surface  ship.  The  collapse  depth  is  the  depth  in  feet 
at  which  the  structural  integrity  of  a  submarine  is  in  danger. 

When  the  user  completes  the  platform  entries,  the  parameters 
are  displayed.  The  user  then  has  the  option  to  save  the  data  on 
the  data  file  or  to  discard  those  entries.  The  processing 
sequence  is  shown  below. 

ENTER  OAT,  PLATFORM  OR  END 

>  (platform) 

ENTER  PLATFORM  NAME  (ALPHANUMERIC) 

>  (name) 

ENTER  PLATFORM  TYPE 

>  (sur,  sub,  air  or  lan) 

ENTER  HULL  RADIUS  (if  type  sur  or  sub) 

>  (hull  radius  in  feet) 

ENTER  HULL  DEPTH  (COLLAPSE  DEPTH  if  type  sub) 

ENTER  NUMBER  OF  OATS 

>  (number) 
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OAT  1  FOR  PLATFORM  (name) 

ENTER  OAT  NAME  (ALPHANUMERIC) 

>  (oat  name) 

.  (repeated  for  each  oat) 

• 

PLATFORM  (name)  IS  TYPE  (target  type) 
HULL  RADIUS  IS  (radius)  FEET 
HULL  DEPTH  IS  (depth)  FEET 
HAS  (nui  jer)  OATS 
OAT  1  IS  (oat  name) 

(repeated  for  each  oat) 

• 

SAVE  THIS  DATA?  (YES  OR  NO) 

>  (yes  or  no) 

ENTER  OAT,  PLATFORM  OR  END 

>  (END  will  terminate  the  BUILD  function) 
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CHAPTER  4 


STUDENT  USERS  GUIDE 


4.1  INTRODUCTION 

The  NWISS  NUCDAM  SYSTEM  was  designed  to  be  a  tactical 
decision  aid  to  the  BGTCSF  student.  The  player  participating  in 
a  tactical  engagement  training  wargame  will  have  the  opportunity 
to  examine  the  possible  effects  of  the  use  of  tactical  nuclear 
weapons  by  either  of  the  forces.  This  system  operates  as  stand 
alone  real-time  support  to  the  student  involved  in  a  BGTCSF 
training.  This  system  has  two  functions  which  are  available  to 
the  player:  TACAID  and  NUCDAM. 

4.2  TACAID  FUNCTION 


The  TACAID  function  is  a  tactical  decision  aid  to  the  player 
during  a  BGTCSF  training  exercise.  The  original  intent  of  TACAID 
was  to  provide  graphics  plots  of  nuclear  environments  but  current 
hardware  limitations  have  forced  the  use  of  tabulated  data  which 
can  be  used  for  hand  plots  or  used  for  graphics  plots  when  the 
hardware  becomes  available.  The  player  is  allowed  to  specify  the 
nuclear  detonation  and  determine  the  effects  which  would  be 
experienced  by  nearby  friendly,  neutral  and  enemy  forces.  This 
will  aid  in  determining  the  aimpoint  if  multiple  kills  are 
possible  or  to  ensure  that  there  is  no  damage  to  friendly  units. 
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The  user  will  specify  the  nuclear  burst  yield  and  height  of 
burst  and  the  height  of  target  at  which  environment  levels  are 
desired.  At  that  point  the  user  may  choose  one  of  two  options: 
RANGE  or  LEVEL.  The  RANGE  option  will  present  data  representing 
an  environment  level  vs  range  plot.  The  user  will  specify  a 
maximum  range  which  represents  the  length  of  the  range  axis,  the 
range  increment  which  represents  the  range  axis  tic  marks,  and 
the  environment  codes  of  interest.  The  LEVEL  option  will  present 
radius  of  effects  contours  for  the  specified  environment  levels. 
The  user  will  specify  the  environment  codes  and  the  levels  of 
interest.  After  the  data  has  been  presented  the  user  may  choose 
to  continue  the  TACAID  function  and  whether  the  same  weapon  and 
target  parameters  are  to  be  used. 

The  following  is  a  sample  sequence  of  the  TACAID  function 
prompts . 

ENTER  PROCESSING  OPTION  < HELP , BUILD, TACAID, NUCDAM, END) 

>  TACAID 

*****  THIS  is  THE  TACAID  FUNCTION  ***** 

ENTER  YIELD  OF  THE  WEAPON  IN  KILOTONS (KT) 

>  1000 

ENTER  HEIGHT  OF  BURST  IN  FEET (NEG  FOR  UNDERWATER) 

>  1000 

ENTER  HEIGHT  OF  TARGET  IN  FT (NEG  FOR  UNDERWATER) 

>0 

ENTER  RANGE  OR  LEVEL 

>  RANGE 

ENTER  MAXIMUM  RANGE  IN  FEET 

> 10000 
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ENTER  RANGE  INCREMENT  IN  FEET 
>  1000 

ENTER  THE  NUMBER  OF  ENVIRONMENTS 
>  2 

ENTER  ENVIRONMENT  CODE  NUMBER  1 

>  4 

ENTER  ENVIRONMENT  CODE  NUMBER  2 

>  5 

YIELDS  1000.0  H0B=  1000.0  HTARG=  0.0 
RANGE  OVERPRESSR  E  M  P 


FEET 

P  S  I 

V  /  M 

1000. 

4366. 

0.3805E+06 

2000. 

459.2 

0.3084E+06 

3000. 

149.8 

0.2271E+06 

4000. 

74.21 

0 . 1428E+06 

5000. 

44.46 

0.7457E+05 

6000. 

30.13 

0.4138E+05 

7000. 

22.02 

0 .2293E+05 

8000. 

16.92 

0.1269E+05 

9000. 

13.49 

7022. 

10000. 

11.07 

3883. 

DO  YOU  WISH  TO  CONTINUE  TACAID?  (YES  OR  NO) 

>  yes 

DO  YOU  WANT  A  NEW  WEAPON  OR  TARGET?  (YES  OR  NO) 

>  no 

ENTER  RANGE  OR  LEVEL 

>  level 

ENTER  THE  NUMBER  OF  ENVIRONMENTS 

>  2 

ENTER  ENVIRONMENT  CODE  NUMBER  1 

>  4 


■  «*.  »•  A  »*  .* 


D-21 


ENTER  ENVIRONMENT  LEVEL 

>  22.02 

ENTER  ENVIRONMENT  CODE  NUMBER  2 

>  5 

ENTER  ENVIRONMENT  LEVEL 

>  7022. 


YIELD=  1000.0  HOB*  1000.0 
ENVIRONMENT  LEVEL  UNITS 

OVERPRESSR  22.02  P  S  I 

E  M  P  7022.  V  /  M 

DO  YOU  WISH  TO  CONTINUE  TACAID? 


HOT*  0.0 
RANGE (FT) 

7001. 

9000. 

(YES  OR  NO) 


>  no 

ENTER  PROCESSING  OPTION  (HELP , BUILD , TACAID , NUCDAM, END) 

> 


4.3  NUCDAM  FUNCTION 


The  BGTCSF  trainee  will  be  able  to  utilize  the  assigned  data 
file  and  the  real-time  vargame  information  in  order  to  operate 
the  NUCDAM  function.  The  NUCDAM  function  provides  specific 
environment  and  damage  level  data  for  a  given  platform  and 
nuclear  detonation  combination.  Depending  on  the  data  which  is 
available  in  the  assigned  data  file,  the  student  will  be  able  to 
examine  the  possible  environment  levels  and  dasttge  which  would  be 
experienced  by  a  specific  enemy,  neutral  or  friendly  platform. 

The  user  will  provide  the  nuclear  weapon  parameters ,  the 
platform  name,  and  the  spacial  relationship  between  the  nuclear 
burst  and  the  target  platform.  The  user  will  have  the  option  to 
enter  the  spacial  relationship  either  as  the  range  in  feet 
between  them  or  to  provide  the  latitude  and  longitude  locations 
from  which  the  NUCDAM  function  will  calculate  the  range. 
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When  ^he  input  parameters  have  been  accepted,  the  data 
concerning  the  target  platform  is  retrieved  from  the  data  file. 
The  nuclear  environments,  impairment  and,  if  available,  the 
damage  and  ETR  data  is  calculated  and  presented  for  each  OAT  of 
the  platform.  Damage  is  accumulated  on  a  scratch  file  during  a 
HU  CD  AM  session.  If  a  target  platform  is  attacked  by  rx>re  than 
one  nurlear  weapon,  the  damage  is  accumulated  and  the  current 
status  of  the  unit  is  presented.  When  a  HUCDAM  function  session 
is  terminated,  the  scratch  file  is  deleted  and  the  data  is  lost. 
To  zero  out  the  damage  accumulation  file,  the  user  can  terminate 
the  NUCDAM  function  session  and  then  reenter  it. 

An  example  of  a  NUCDAM  function  prompt  sequence  is  shown 
below. 

ENTER  PROCESSING  OPTION  (HELP, BUILD, TACAID, NUCDAM, END) 

>  NUCDAM 

*****  XHIS  IS  the  HUCDAM  FUNCTION  ***** 

ENTER  FILE  NAME 

>  (filename. type; version) 

FILE  (filename, type;version)  HAS  BEEN  OPENED 

ENTER  THE  TARGET  PLATFORM  NAME 

>  DESTROYER 

ENTER  HEIGHT  OF  BURST  IN  FEET (NEG  FOR  UNDERWATER) 

>  1000. 

ENTER  YIELD  OF  WEAPON  IN  KILOTONS (KT) 

>-  1000. 

ENTER  RANGE  OR  LOCATION  (OPTION) 

>  RANGE 


ENTER  THE  RANGE  IN  FEET  FROM  THE  TARGET  TO  THE  HURST  PT 

>  10000. 


platform  destroyer 

YIELD*  1000.0  HOB*  1000.0  HOT* 

OAT  ENV1R0MWT  ENVIROIf«T  ENVIRONMNT 

LEVEL  UNITS 


SEAWORTHY 

0VERPRESSR 

11.07 

P  S  1 

MOBILITY 

0VERPRESSR 

11.07 

P  S  I 

HPHDLVRY 

OVERPRESSR 

THERMAL 

11.07 

181.2 

P  S  1 
CAL/CM**2 

PERSONNEL 

OVERPRESSR 
TISSUE  ION 

11.07 

39.82 

P  S  I 
REMS 

0.0  RANGE*  10000. 

IMPAIRMENT  AVAILABILITY  ETR 

HOURS 


0.4275E-01 

0.7139 

1.0000 

1.0000 

0.000OE4O0 

0.2632E-02 


65.73 
28.61 

0.0000£*00 

O.OOOOE+OQ 

99.74 

99.74 


31.33 

0.1000E7 

0.1000E7 

0.1000E7 

105.3 

105.3 


DO  YOU  WANT  TO  CONTINUE  NUCDAM?  (YES  OR  NO)  . 

>  no  s 


ENTER  PROCESSING  OPTION  (HELP* BUILD, TACAID,  HUCDAM*END) 


When  the  user  has  finished  with  the  NUCDAM  function,  it  nay 
be  terminated  and  then  the  user  nay  choose  another  function  or 
terminate  the  NWISS  NUCDAM  SYSTEM  session. 
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